いま最も広い攻撃面は、 御社のクラウドです。
AWS・Azure・GCP における設定、アイデンティティ、分離の見直しです。クラウドの事故の多くは事業者側の障害から始まりません。広すぎる権限、意図せず公開されたリソース、忘れられた秘密情報から始まります。
クラウドでは、原因が事業者側にあることはまれです
責任共有モデルは役割を分けます。インフラの安全は事業者が担い、設定は御社の担当です。事故は御社側で起きます。検証の都合で開けたバケット、急ぎのため管理者権限を与えたロール、期日に追われて分離しないまま置かれたネットワーク。どれもスキャンでは脆弱性として現れません。誰も見直さなかった設定上の判断として現れます。
- 暫定措置として与えた権限が、後から取り消されることはほとんどありません。
- 標準の手順を通さずに作られたリソースは、その手順が与える保護を受け継ぎません。
- 環境変数やリポジトリの中の秘密情報は、いまも侵入までの最短経路です。
- 分離がなければ、ひとつの足がかりが、分かれているはずのアカウントや環境にまで届きます。
実施内容
以下は標準的な案件での既定の範囲です。スコーピングの段階で、いずれも無償で調整できます。
- 広すぎるポリシー、アクションとリソースのワイルドカード
- 引き受け可能なロールと権限昇格の連鎖
- 長期間有効なアクセスキーとローテーション
- フェデレーション、ID プロバイダ、セッション
- サービスアカウントとワークロードの権限
- 管理業務と運用業務の分離
- オブジェクトやコンテナの公開状態
- 保存時の暗号化と鍵の管理
- アクセスポリシーとアカウント間の共有
- バージョン管理、保持期間、削除防止
- バックアップと復旧の実地確認
- 本来の保管場所の外にある機微データ
- インターネット全体に開いた受信ルール
- 環境間およびアカウント間の分離
- ロードバランサー、ゲートウェイ、通信の終端
- 外部から到達できる管理系サービス
- プライベート接続とネットワークピアリング
- コンテナとオーケストレーションの攻撃面
- すべてのリージョンで有効な監査証跡
- ログ自体の保持と保護
- コントロールプレーンのイベント網羅
- 機微な権限変更に対するアラート
- 別アカウントへの集約
- 既存の監視基盤との連携
- IAM、ロール、ポリシー、ID フェデレーション
- VPC、セキュリティグループ、NACL、ピアリング、公開状態
- S3、RDS、DynamoDB、Blob Storage、Cloud Storage
- EC2、Lambda、ECS、EKS、AKS、GKE
- CloudTrail、AWS Config、Microsoft Sentinel、Security Command Center
- ID プロバイダとフェデレーション型 SSO
実施形態
範囲に応じて調整設定レビュー
読み取り専用の監査ロールから環境を体系的に確認します。アイデンティティ、ネットワーク、ストレージ、ログ、データ保護を、事業者自身のドキュメントと公開ベンチマークに照らします。
経路の検証
設定を並べるのではなく、ありうる出発点——アプリケーションの認証情報、侵害されたコンテナ、一般利用者——から始め、環境内でどこまで届くかを確かめます。
継続的レビューと Infrastructure as Code
環境を構築するテンプレートとモジュールを分析し、定期的な確認の周期を設けます。元を直せば、同じ逸脱が新しいアカウント・プロジェクト・デプロイのたびに戻ってくることはありません。
クラウド環境を見直すべきとき
クラウドの設定は多くの人の手で日々変わります。リスクがとりわけ集まる時期があります。
急いで移した環境には、切り替えを通すために与えられた広い権限が残りがちです。後で絞るという約束つきで——そしてその「後で」はめったに来ません。
チームごとにひとつ、プロジェクトごとにもうひとつ。中心となる基準がなければ保護はばらつき、全体を見渡せる人もいなくなります。
異常なコストは、無駄遣いのこともあれば、作成権限を持つべきでない人が作ったリソースのこともあります。どちらなのかは知っておく価値があります。
クラウド統制の証跡は、いまや多くの質問票で定番の項目です。評価者より先に不足を見つけておくほうが得策です。
進め方
[パイプライン]環境の把握
まず、何が存在するのかから始めます。アカウント、サブスクリプション、プロジェクト、有効なリージョン、稼働中のリソース。クラウド環境はたいていドキュメントより大きく、台帳から漏れているリソースこそ保護されていないことが多いのです。
アイデンティティと権限の分析
誰が何をできるかを、継承やロールの引き受けによって可能になる範囲まで含めて整理します。要点は書かれたポリシーではなく実効的な権限であり、それは付与した本人の想定よりずっと広いのが常です。
設定の確認
ストレージ、ネットワーク、暗号化、ログ、バックアップ、マネージドサービスを、事業者のドキュメントと公開されている安全設定ベンチマークに照らします。逸脱ごとに、その環境で何が問題になるのかを添えて記録します。
到達範囲の確認
現実的な出発点を再現し、それぞれの到達範囲を測ります。アプリケーションの認証情報で何が読めるのか、侵害されたコンテナが何に触れるのか、ある環境から別の環境へ渡れるのか。これが、逸脱の一覧を実証されたリスクに変えます。
ログとアラートの評価
実行した操作が証跡を残したか、その証跡が削除から守られているか、機微な権限変更でアラートが上がるかを確認します。信頼できる証跡のない環境は、事故の後に調査ができません。
報告と是正計画
逸脱はリソース単位ではなく原因単位でまとめます。ひとつのポリシーに由来する十件は、十件の修正ではなく一件です。各グループに実行可能な指針と、元から再発を防ぐための提案を添えます。
作業の根拠となる公開基準
確認は事業者自身のドキュメントと公開された設定ベンチマークに立脚しており、そのため各項目は独立して検証できます。
- CIS Benchmarks
- AWS・Azure・GCP 向けの設定基準です。環境の状態を照らし合わせるための、項目ごとの客観的な参照になります。
- Well-Architected（セキュリティの柱）
- 各事業者の設計指針は、彼ら自身が推奨する実践を明示しています。推奨の出どころをめぐる議論が起きません。
- 責任共有モデル
- 事業者の責任がどこで終わり、御社の責任がどこから始まるかを厳密に定義します。事故の大半が起きるのは、まさにこの境界です。
- MITRE ATT&CK for Cloud
- クラウドに特化した一覧で、アイデンティティの悪用、居座り、情報収集の手法に名前を与えます。検知の網羅度を評価する材料になります。
- NIST SP 800-53
- 管理策のカタログは、技術的な指摘と、ガバナンスや監査がすでに使っている言葉とを橋渡しします。
- 最小権限
- 標準ではなく、権限分析を導く判断基準です。あらゆるアイデンティティは必要な範囲にだけ届くべきで、そこから外れるなら明示的な理由が要ります。
- Azure Security Benchmark
- Microsoft 自身による Azure 向けの基準です。環境が Azure 中心で、監査側がこの参照を前提にする場合に用います。
- CSA Cloud Controls Matrix
- Cloud Security Alliance のマトリクスはクラウドセキュリティの領域を整理し、他の規格との対応も示します。取引先の質問票が長いときに助けになります。
- ISO/IEC 27017 および 27018
- クラウドのセキュリティと、クラウド上の個人データに特化した規格で、法人契約でよく引用されます。
- データ保護法制・PCI-DSS との対応づけ
- 環境が個人データやカード会員データを扱う場合、各指摘を該当する要件にも紐づけ、そのまま証跡として使える形にします。
成果物
二層構成 · NDA実在するものの一覧
アカウント、プロジェクト、リージョン、稼働中リソースの実際の一覧です。誰も自分たちの持ち物だと覚えていなかった環境が出てくるため、多くのチームにとって最初に役立つ成果物になります。
実効権限のマップ
実務上、誰が何に届くのか。継承やロールの引き受けによる間接的な経路も含みます。設定の一覧より驚きが大きいのが普通です。
原因ごとにまとめた逸脱
共通の出どころで整理した指摘に、それぞれ公開されている参照を添えます。原因を直せば複数の項目が同時に閉じ、再発も防げます。
実証された経路
重要度の高いリスクについては具体的な道筋を示します。どこから始まり、何に届き、なぜそれが問題なのか。設定上の逸脱が、専門家でなくても重みを判断できるリスクに変わります。
証跡と検知の評価
実行した操作のうち何が記録されたか、何が無効化されていたか、そして現状ではどの機微な変更が気づかれずに通るのか。
優先順位をつけた是正計画
リスクと手間を秤にかけた作業順序です。設定で直せるものと、再発させないために Infrastructure as Code 側で変えるべきものを分けて示します。
よくある質問
不要です。確認は読み取り専用の監査ロールから行います。三事業者いずれも標準で用意しています。到達範囲の検証に使う認証情報は別途、限定された形で取り決め、範囲と有効期間を書面に定めます。
置き換えではなく補完です。姿勢管理ツールは量をさばき、設定のずれを継続的に追えます。そこは価値があります。できないのは、権限をつなげて、アプリケーションの認証情報が隔離されているはずのデータに届くと示すことです。優先順位を変えるのは、その実証のほうです。
対応します。混在環境のほうが一般的で、事業者どうしを比べると保護の不揃いがよく見えます。同じ種類のリソースが一方では閉じられ、もう一方では開いている。作ったチームが違うからです。
オーケストレーションも対象です。ロールとバインディング、コンテナのセキュリティコンテキスト、サービス間のネットワークポリシー、コントロールプレーンの露出、秘密情報の管理、そしてクラスタのアイデンティティとクラウドのアイデンティティの結び付き——よくある昇格経路です。
少なくとも本番を支える範囲です。開発やステージングのアカウントも、ネットワークやアイデンティティの経路で本番につながっているなら含める価値があります。そうした例は想像より多く、しかもそこは保護が最も緩みがちです。
元で直すことです。環境が Infrastructure as Code から作られているなら、修正はモジュールに入れれば以後のすべてのデプロイに効きます。報告書では逸脱のグループごとに、リソース側で扱うべきか、それを生成するテンプレート側で扱うべきかを明記します。
使えます。各項目に公開された参照と、観測された設定の証跡が付いており、監査人が分析をやり直さずに自分で検証できる形式になっています。