クラウドのセキュリティインシデントの多くは、クラウド事業者自身のインフラが破られることによるものではありません。原因は利用者側の設定にあります。公開されたままのストレージバケット、リポジトリにコミットされたアクセスキー、多要素認証のない管理者アカウント、インターネット全体から到達できるデータベースなどです。クラウド事業者は責任共有モデルを採用しており、事業者が基盤となるプラットフォームを保護し、利用者はその上で設定するものを保護します。本ガイドでは、クラウドの設定ミスで多いリスクと、それぞれの実践的な確認方法を紹介します。
何であるのか
クラウドの設定ミスとは、クラウドアカウント内の設定のうち、データやシステムを意図以上に露出させるもの、または問題を検知して復旧できない状態にするもののことです。設定ミスは、チームの拡大、プロジェクトの迅速な作成、一時的な変更の恒久化に伴って蓄積しがちです。主なカテゴリーはAWS、Microsoft Azure、Google Cloudで共通しています。IDとアクセス：過度に広いロール、長期間有効なアクセスキー、共有アカウント、MFAの未設定。ストレージ：誰でも読み取れる、または過度に広く共有されたバケット、Blob、スナップショット。ネットワーク：すべてのアドレスに開かれたセキュリティグループやファイアウォールルール、公開された管理用ポート、セグメント化されていないフラットなネットワーク。シークレット：コード、環境ファイル、コンテナイメージ内の認証情報。ログ記録：監査ログが無効、保持されていない、または一度も確認されていない。暗号化：機微なデータが暗号化されずに保存されている、または鍵の管理が不十分。レジリエンス：バックアップがない、テストされていない、または保護対象と同じアカウントに保存されている。ガバナンス：把握されていないアカウント、タグのないリソース、担当者のいないプロジェクト。
誰のために
このチェックリストは次のような方に役立ちます。
- 正式な設計なしにクラウド環境が急速に拡大したスタートアップや中小企業
- 顧客のセキュリティレビューやデューデリジェンスに備えているチーム
- クラウドでAIやデータのワークロードを運用する予定の組織
- 元従業員やサプライヤーからクラウドアカウントを引き継いだマネージャー
明確にするのに役立つこと
チェックリストに沿って確認することで、次の点が明確になります。
- 誰が管理者アクセスを持ち、それが保護され、今も必要なのか
- 意図的かどうかにかかわらず、どのデータが公開状態で到達可能か
- 不審な活動に気づき、調査できるか
- アカウントが侵害された場合に、重要なシステムを復元できるか
含まれる内容
- すべての人間のユーザー、特に管理者とルートまたはオーナーアカウントにMFAを必須とする
- 可能な場合は、長期間有効なアクセスキーをロールや短期間の認証情報に置き換える
- 最小権限の観点でロールを見直し、使われていないユーザーと権限を削除する
- ストレージへのパブリックアクセスを既定でブロックし、例外を見直す
- 管理用ポートとデータベースを、既知のネットワークまたはプライベートアクセスに限定する
- シークレットをマネージドなシークレットサービスに移し、漏えいしたキーがないかリポジトリをスキャンする
- 利用しているすべてのアカウントとリージョンで監査ログを有効にし、ログを安全に保持する
- 新しい管理者の追加、ログ記録の無効化、ストレージの公開など、リスクの高いイベントにアラートを設定する
- 機微なデータを保存時に暗号化し、鍵を管理できる人を制御する
- 重要なデータを別のアカウントまたは場所にバックアップし、復元をテストする
- アカウント、プロジェクト、リソースの担当者の一覧を維持する
- Infrastructure as Codeを使い、適用前に変更をレビューする
含まれていないもの
- レビュー済みの環境は侵害されないという主張
- 正式なクラウド監査、認証、コンプライアンス上の承認
- 別途スコープを定めない限り、ペネトレーションテスト
- 別途合意がない限り、継続的な監視やマネージド運用
それを選ぶべきとき
クラウドアカウントをしばらく見直していない場合、顧客や投資家のセキュリティレビューの前、スタッフやサプライヤーの変更後、そしてAIや大規模なデータのワークロードを導入する前に、このチェックリストを使ってください。すべてのアカウントで誰が管理者アクセスを持っているかをすぐに答えられない場合は、そこから始めてください。
私たちのアプローチ
他の多くの管理策がIDに依存しているため、まずIDを優先してください。次に、公開状態の露出を取り除き、シークレットを保護し、ログ記録とバックアップが検知と復旧を支えられるようにしてください。修正は一度きりの片付けではなく、担当者と変更管理を伴うエンジニアリング作業として扱ってください。当社のCloud Platform & Production Engineering サービスは、合意した環境について、アーキテクチャの判断、リリースパイプライン、オブザーバビリティ、バックアップ、復旧の手順書を対象とし、本番環境の変更は、承認された計画と明示的な書面による許可がある場合にのみ行います。まず現状を文書化して把握する必要がある場合は、Security Baseline Reviewで深刻度別の指摘事項を提供でき、AI & Cloud Readiness レビューでは、AIワークロードの基盤に焦点を当てた準備状況のスコアカードと判断記録を提供します。クラウド上でホストされるアプリケーションのペネトレーションテストは、別途スコープを定めることができます。チームやプロジェクトが変わるにつれて設定はずれていくため、チェックリストを定期的に見直してください。
よくある質問
関連記事
始めよう
クラウドの設定状況をより明確に把握したいですか？
利用している事業者とアカウント、そこで稼働しているもの、予定しているレビューや移行についてお知らせください。書面のスコープをご提案します。
書面のスコープを依頼する