サイバーセキュリティ意識向上月間、結局は「基本」に立ち返る理由

シニア・サイバーセキュリティ・ストラテジスト

アイデンティティとアクセス管理

• 昇格権限を持つすべての人間のアカウント、特にクラウド管理者とルートにMFAを強制する。「この管理者だけ」という例外は認めない。
• サービスアカウントには、長期有効なキーではなく、短期間で失効する認証情報とワークロードアイデンティティを使う。 
• 人間・非人間を問わず、すべてのアイデンティティに最小権限の考え方を適用する。サービスアカウントやCI/CDパイプラインへの過剰な権限は、人間のアカウントへの過剰な権限と同等か、それ以上に危険である。脅威アクターによる標的化が増えているためだ。
• アクセス権の監査と取り消しは、思いつきではなく定期的なサイクルで行う。移行作業、インシデント調査、マーケティング施策のために付与した一時的なアクセスは、半年も残らず自動的に失効させる。（アクセスレビューのプロセスは、全面的な自動化を真剣に検討してください。）
• 認証情報とAPIキーは決まったサイクルでローテーションし、人事異動やサードパーティサービスの契約終了の際にも直ちに実施する。（これも自動化できます。）
• 初回ログイン時だけでなく、ランタイムでも異常なアイデンティティの挙動を監視する。有効な認証情報であっても、これまでにない操作、未経験の場所からのログイン、不自然な時間帯の利用は、依然として警告シグナルである。

脆弱性とパッチの管理

• CVSSスコアだけでなく、悪用可能性と露出度に基づいてパッチを適用する。インターネットに面したワークロードにある中程度の深刻度の欠陥は、三層奥に埋もれた重大な欠陥よりも先に悪用される。
• 修復のギャップを埋める。CISAのKEVカタログに掲載された重大な脆弱性のうち、昨年に完全に修復されたのは26%にとどまる。修復までの時間は、補足事項ではなくKPIとして追跡する。
• イメージと依存関係は本番環境に到達する前にスキャンし、稼働中のワークロードも継続的にスキャンする。今日クリーンなイメージでも、明日には新たなCVEが見つかる可能性があるためだ。
• 正確なソフトウェアインベントリ（SBOM）を維持し、新たなCVEが公開された際に、実際に何が稼働しているかを把握できるようにする。見えないものにパッチは当てられない。

クラウドとKubernetesの構成

• 企業全体のすべてのアカウントに対して、継続的にポスチャチェックを実施する。構成は静的スキャンの合間にずれる可能性があるため、継続的にスキャンする。
• ストレージはデフォルトで閉じ、必要な場合にのみ公開する。パブリックバケットやオープンなBLOBは、クラウドサービスプロバイダーで頻発する、防げるはずの露出経路である。
• ネットワークの露出を制限する。未使用のポートを閉じ、セキュリティグループを絞り込み、急いでいたという理由で許容的なファイアウォールルールが標準になることを許さない。Kubernetesでは、Podの通信がデフォルトで名前空間をまたいで開放されているため、ネットワークポリシーを追加する。
• KubernetesのRBACは最小権限にスコープする。可能な限り、クラスタ全体のロールではなく名前空間単位のRoleを使う。cluster-adminのバインディングは、いずれも担当者が必要な例外として扱う。cluster-adminを安易に配れば、横展開の問題を招くことになるからだ。
• Podの権限昇格、hostPathマウント、特権コンテナは、正当な理由がない限り無効化するか、厳しくスコープする。理由がある場合は、異常な使われ方がないか挙動を監視する。

ランタイムでの検知と対応

• すべてのワークロードにランタイムセンサーを配備する。ビルド時の静的スキャンでは、デプロイ後に起きることを捉えられないためだ。 
• ドリフトは発生した瞬間に検知する。元のイメージに含まれていなかったバイナリをコンテナが実行し始めたら、それは危険信号である。
• 検知結果をMITRE ATT&CKにマッピングすれば、「何かが作動したが、何が起きたのか」ではなく、どの手法を相手にして対応しているのかをチームが把握できる。
• アラートは、自社環境の実際の挙動ベースラインに合わせて調整する。アラート疲れはトリアージの速度を落とし、誤検知は貴重な時間を無駄にする。
• 確度の高いアラートが発生したときにすぐ実行できる、検証済みの封じ込め措置を用意しておく。対応プレイブックのない検知は、侵害が進行する様子を記録するだけで、ただ眺めることになる。

ログ、監視、可視化

• クラウド、コンテナ、アイデンティティの各レイヤーのログを一元化する。ログが分断されていれば調査も分断され、対応は遅れる。
• あらゆる場所で監査ログを有効にし、想定どおりの内容が実際に記録されているかを確認する。 
• 調査に足りる期間、ログを保持する。特定と封じ込めにかかる平均時間は247日であり、30日間のデータ保持ではその12%しかカバーできない。
• レイヤーをまたいでシグナルを相関させる。同じワークロードで起きたIAMの異常とランタイムの異常は、それぞれ単独で見る場合とは意味が異なる。

サプライチェーンとCI/CDの管理

• サードパーティの依存関係とコンテナのベースイメージは、取り込み時だけでなく継続的にスキャンする。
• CI/CDの認証情報とパイプラインの権限は、本番環境へのアクセスと同じ厳しさで扱う。パイプラインが侵害されれば、本番環境も侵害される。
• ベンダーやパートナーのアクセスを審査し、監視する。現在、サードパーティは侵害の48%に関与している。
• パイプライン全体でアーティファクトに署名して検証し、未検証のものがランタイム環境に到達しないようにする。

ガバナンス

• このリストにある基本事項のすべてに、明確な担当者を割り当てる。「セキュリティは全員の責任」で止まってしまうと、対策は抜け落ちる。
• 承認されたものを文書化する（AIツールも例外ではない）。承認済みツール、入力してよいデータ、新規ツールの承認者に関するポリシーを定める。AI関連のインシデントを経験した組織のうち、68%はAIガバナンスポリシーを持っていなかった。
• 定めたポリシーは徹底する。利用状況を検知できない禁止措置は、単なる提案にすぎない。
• 例外を認める場合は、担当者と有効期限を設定する。
• 確立されたフレームワークを拠り所にする。たとえば、AIリスクにはNIST AI RMFを使い、OWASP Top 10 for LLM Applicationsを補完的な脅威チェックリストとして活用する。
• これらの基本は、毎年10月だけでなく、実際に定めたサイクルで見直す。

人とプロセスの管理

• メールの添付ファイルだけでなく、ボイスフィッシング、MFA疲労攻撃、ヘルプデスクへのなりすましなど、現在実際に見られるソーシャルエンジニアリングを想定して訓練する。
• インシデントが起きる前に、実際に対応にあたる担当者とともにインシデント対応を演習する。
• 経営層には定期的に指標を報告する。特権アカウントのMFA適用率、最小権限になっているアイデンティティの割合、既知の悪用された脆弱性の修復までの時間などを含める。