2026年10月8日にOWASP API Security Top 10、OWASP Secrets Management Cheat Sheet、RFC 8446の本文を再確認した。セキュリティは「機能を付けること」ではなく、守る資産と脅威を定義し、認証・認可、秘密情報の発行/保管/ローテーション、通信路保護、入力・出力、監視と復旧を組み合わせて確かめる運用である。TLSやsecret manager、JWT、WAFの導入は一つの制御に過ぎず、権限境界・設定・失効・ログ・復旧の証拠が揃って初めて判断できる。
30秒で要点
- セキュリティは、情報や仕事を、勝手に見られる・書き換えられる・使えなくなる状態から守る取り組みです。事故をゼロにする保証ではありません。
- パスワード、複数要素認証、暗号化、通信の制限、更新を組み合わせます。導入した名前だけでなく、対象と設定、管理する人を確認します。
- バックアップは、保存しただけで終わらせず、必要な情報を戻せるか試します。異常を見つけたときの連絡先と初動も、平時に決めておきます。
家で鍵を掛けても、鍵を誰に渡すか、窓を開けたままにしないか、火災や故障にどう備えるかは別の問題です。情報システムも同じで、一つの製品を入れれば終わりにはなりません。守りたいものと、起こると困る状態を整理すると、必要な対策を選びやすくなります。
情報・システム・事業の何を守るのか
情報セキュリティでは、情報を許可された人だけが扱えること、勝手に壊したり書き換えたりされないこと、必要なときに使えることを考えます。専門用語では、機密性・完全性・可用性と呼びます。NISTの用語定義
表が収まらない場合は、横にスクロールできます
| 観点 | 身近な例 | 守りたい状態 |
|---|---|---|
| 機密性 | 顧客の住所、管理画面へのログイン情報 | 必要な人だけが見たり使ったりできる |
| 完全性 | 請求額、商品の価格、予約内容 | 意図しない変更を防ぎ、変更を追える |
| 可用性 | 予約受付、業務ファイル、連絡手段 | 必要な時に使え、止まった時に回復できる |
顧客情報だけが対象ではありません。公開してよい営業時間でも、第三者が書き換えれば来店客が困ります。秘密のない案内サイトでも、長時間止まれば業務に影響します。「公開情報だから対策不要」とは判断しないでください。
ログイン、ネットバンキング、Webサイト、社内の共有ファイルでは、利用者と管理者の責任も違います。利用者は認証や送信先を確認し、管理者は権限、更新、記録、復旧を整えます。委託やクラウドを使う場合も、契約やサービスの範囲を確認して、誰が何を設定するかを明確にします。
よくある四つの脅威を、結果から考える
悪意あるソフトウェア
マルウェアは、情報を盗む、破壊する、暗号化して使えなくするなど、悪意ある動作をするソフトウェアの総称です。ウイルスはその一種で、すべてを同じ呼び方で扱うと対策の対象を見誤ります。
不審な添付ファイルだけでなく、更新されていないソフトウェアや、権限の広すぎる端末も確認します。検出ソフトを入れたことだけで、侵入も被害も起きないとはしません。
本物を装って情報や操作を求めるフィッシング
メールやメッセージで、ログイン、送金、認証コードの入力などを促す手口です。見た目や差出人表示だけで判断せず、普段使う公式の入口や、あらかじめ確認済みの連絡先から確かめます。
「急いでいる」と言われても、送金先変更や管理者権限の付与を、そのメッセージだけで決めない運用が必要です。確認のために、相手が新しく指定した番号だけへ電話するのでは、別経路の確認にならない場合があります。
許可されていないアクセスや操作
盗まれた認証情報、不要になったアカウント、広すぎる権限などから、第三者が情報を見たり変更したりする場合があります。ログインできたことと、すべての情報を扱ってよいことは別です。
共有アカウントを安易に増やさず、誰が何をできるかを整理します。異動・退職・委託終了時に権限を見直す担当と、確認する期限も決めます。
消失、誤操作、故障
事故は攻撃だけではありません。誤削除、端末故障、設定変更、災害などでも情報が使えなくなります。同期先でも同時に削除が反映される構成では、同期だけを復旧手段と考えると困る場合があります。
バックアップ、変更履歴、別の連絡方法、復旧手順を、起きると困る状態に合わせて用意します。人が間違えることを前提に、間違いに気付き、戻せる仕組みを考えます。
五つの対策と、その守備範囲
1. パスワード：長さと使い回し、管理方法を確認する
利用者としては、サービスごとに異なる十分に長いパスワードを使い、管理ツールの利用や復旧方法を検討します。長くても、偽サイトへ入力したり、同じものを使い回したりすれば、別の危険が残ります。
「8文字以上で英大文字・小文字・数字・記号を混ぜ、定期的に変更すれば安全」という一律の説明は適切ではありません。NIST SP 800-63B-4のパスワード検証側の要件では、単一要素として使うパスワードは最低15文字、複数要素認証の一部としてのみ使う場合は最低8文字まで許容しています。文字種の混在を追加で強制せず、理由のない定期変更も要求しない一方、漏洩の証拠がある場合は変更を求めます。NISTのパスワード要件3.1.1
これは認証サービスを設計する側の条件で、すべての日本の事業者へ同じ法的義務があるという意味ではありません。また、15文字なら安全という認定でもありません。漏洩済み候補の照合、試行回数の制限、安全な保存、複数要素認証なども必要です。端末を開くためのPINと、サーバーへ送るパスワードを同じ条件で説明しないようにします。
利用中のサービスに古い制約があっても、勝手に設定を解除するのではなく、提供者の対応範囲と代替策を確認します。漏洩が疑われる場合の変更、セッションの失効、関連サービスの確認は、普段の定期変更とは区別して扱います。
2. 複数要素認証：二回入力することとは違う
MFAは、知っているもの、持っているもの、身体的な特徴など、異なる種類の要素を組み合わせる認証です。パスワードと秘密の質問を二回入力するだけでは、異なる要素の組合せにはなりません。
SMSやワンタイムコードにも、偽サイトへ入力させられる危険があります。利用できるサービスでは、フィッシングに耐性のある方式を検討し、とくに管理者や重要情報を扱うアカウントから確認します。NISTのMFA解説
設定するだけでなく、端末紛失、担当者の退職、認証手段の故障に備えます。復旧用の情報を誰が保管し、本人確認をどう行うかを決め、認証コードや復旧コードをチャットや共有資料へ貼り付けないようにします。
3. 暗号化：通信中と保存後を分ける
HTTPSで使われるTLSは、ブラウザと接続先の間でやり取りする情報を保護し、通信の改ざん検出や接続先の認証を支えます。MDNのTLS解説
ただし、HTTPSの表示だけでは、その事業者が信頼できることや、受信後の情報が安全に保管されることは分かりません。端末の侵害、誤った送信先、正規の権限を持つ人の操作は別に考えます。
Webサイトでは、ページだけでなく画像やスクリプトも含めた通信、証明書の管理、管理画面への接続を確認します。保存するファイルやバックアップの暗号化は別の設定です。暗号化したデータを戻す鍵を失えば、自分たちも復旧できなくなる場合があります。
4. 通信と権限の制限：必要な入口だけにする
ファイアウォールは、決めたルールに沿って通信を制御する仕組みです。不要な入口を閉じるために使いますが、許可した通信の中で起きるすべての悪意ある操作を検知するものではありません。
「接続できる人」と「接続した後にできる操作」を分けて確認します。例えば、公開サイトは閲覧できても、管理画面を誰でも操作できてよいわけではありません。設定を厳しくしすぎて必要な業務が止まる場合もあるため、対象、理由、確認方法、戻し方を記録します。
5. 更新：対象の把握から、更新後の確認まで
OS、ブラウザ、アプリ、拡張機能、機器など、何を使っているか分からないと、更新が必要か判断できません。更新には不具合や脆弱性への対応が含まれます。サポートが終了したものは、更新され続ける前提で運用しないでください。
更新の責任者、通知の受け先、業務への影響、事前のバックアップ、更新後に確認する機能を決めます。重大な危険がある場合に、定例日まで待てばよいとも限りません。緊急度と業務影響を管理者が判断できるようにします。NISTの基本対策
保存できたバックアップを、戻せる備えにする
NISTの基本対策でも、バックアップを保護し、試験することが挙げられています。保存成功の表示と、必要な仕事を再開できることは別です。
表が収まらない場合は、横にスクロールできます
| 確認する項目 | 小さな確認の例 |
|---|---|
| 何を戻すか | ファイルだけか、設定・権限・台帳も必要かを列挙 |
| どの時点まで戻れるか | 最後の正常な保存時刻と、保存されない変更を確認 |
| 誰が戻せるか | 担当者不在でも手順と認証手段を使えるか確認 |
| 保存先も被害を受けないか | 同じ権限・同じ端末の事故で一緒に失われないか確認 |
| 本当に使えるか | 本番を上書きしない隔離先で、復元した一部の情報を開く |
説明用に、営業開始が9時、最後の正常なバックアップが12時、障害が15時だったとします。ほかに復元手段がなければ、12時から15時までの最大3時間分の変更が戻らない可能性があります。これは「3時間で復旧できる」という意味ではありません。失う可能性のある期間と、復旧にかかる時間は別です。
この記事では実際のバックアップや復元を実行していません。試すときは、対象、隔離先、使用する認証情報、誤って本番を上書きしない条件を決め、失敗した場合も結果を残します。秘密情報を証拠の画像やログに写さない配慮も必要です。
対策の優先順位は、被害と業務の条件で決める
「個人サイトは低、会社は中、金融は高」といった分類だけでは、自分たちが何をすべきか決まりません。止まると困る業務、扱う情報、外部から到達できる入口、管理者の権限、事故に気付く方法を確認します。
最初は、次の順にメモを作る方法を提案します。これは固定の実施順や、緊急対応を遅らせる理由ではありません。
- 守る対象を一つ選ぶ。 予約台帳、経理アカウントなど、具体的にします。
- 困る状態を三つに分ける。 見られる、書き換えられる、使えなくなる、を考えます。
- 利用者と管理者を確認する。 外部委託先を含め、権限と連絡先を整理します。
- 現在の対策が動くか確かめる。 設定済みという申告だけでなく、対象と確認結果を残します。
- 残る危険と次の作業を決める。 担当、期限、業務への影響、戻し方を記録します。
情報の取り扱いには、法律や契約で求められる条件が関係する場合があります。一般的な対策一覧を満たしたことだけで、法令順守や取引先の条件まで満たしたとはしないでください。
異常に気付いたとき、迷わないために
不審なログイン、身に覚えのない送信、ファイルが開けないなどの異常が起きたとき、誰へ何を伝えるかを決めます。使えなくなる可能性のある社内メールだけに連絡先を置かず、別の連絡方法も用意します。
平時に作るメモには、発見時刻、見えた症状、対象機器やアカウント、直前の操作、連絡先を含めます。急いで初期化・削除したり、原因を確かめるために怪しいファイルを開いたりせず、組織の手順に沿って、管理者が隔離や停止、記録の保全を判断できるようにします。
顧客への通知、行政への報告、外部支援の要否は、事実と対象の条件に基づく判断が必要です。この記事の入門的な整理だけで、個別事故の対応や法的義務を確定しないでください。
覚えておきたい言葉
表が収まらない場合は、横にスクロールできます
| 言葉 | 意味 | 混同しないこと |
|---|---|---|
| 脆弱性 | 悪用される可能性がある弱点 | 見つかっただけで被害が発生したとは限らない |
| パッチ | 問題へ対応する更新 | 適用した対象と結果の確認が必要 |
| マルウェア | 悪意ある動作をするソフトウェア | ウイルスはその一種 |
| フィッシング | 本物を装い情報や操作を求める手口 | HTTPSや見た目だけでは見分けられない |
| 認証・権限 | 誰かを確認すること・何を許すか | ログイン後の操作範囲は別に制御 |
| バックアップ・復旧 | 戻すための保存・使える状態へ戻す作業 | 保存成功だけで復旧成功とはいえない |
サイト運用の責任とつなげる
- サーバー側の役割：サーバーの入門
- 委託しても残る管理：クラウドの入門
- 認証情報の扱い：APIキーと秘密情報の管理
- 継続的な更新と復元：WordPressの保守