クラウドセキュリティは新しいものではありません。実際、かなりの年数が経っています。
しかし、毎年時が経つにつれてクラウドはより複雑になり、その複雑さとともに新たなリスクが生じます。
10年前、クラウドはストレージとコンピューティングが主な用途でした。しかし今日では、API、ID、AIワークロード、そしてビジネス全体がクラウド上に構築されています。これは、アタックサーフェス（攻撃対象領域）が決して縮小せず、拡大し続けていることを示しています。
それにもかかわらず、多くの組織では依然としてクラウドセキュリティをチェックリストのように扱っています。例えば、データの暗号化、MFAの追加、定期的なスキャンといった具合です。
しかし実際には、ご存知のように、たった一つの設定ミスがすり抜けてしまうことがあります。一つの権限の乱用、一つのシャドーITの侵入。そして、それだけで攻撃者は脆弱性を見つけるのに十分なのです。
その罠に陥らないようにする1つの方法は、クラウドセキュリティのベストプラクティスに従うことです。それは決まり文句としてだけでなく、安全なクラウド環境を構築・維持するための基本的なアプローチとして重要です。
この記事では、脅威の一歩先を行き、データ、アプリケーション、ユーザーを保護するために、すべての組織が従うべき25のクラウドセキュリティのベストプラクティスを学びます。
しかし、まず、クラウドセキュリティがなぜ重要であり、かつ困難であるのかを理解しましょう。
なぜクラウドセキュリティは重要であり、かつ課題が多いのか
オンプレミスからクラウドへの移行は、すべてを変えました。突然、チームは数ヶ月ではなく数分で必要なハードウェアを入手できるようになり、初期費用もほとんどかからなくなりました。このスピードはイノベーションを解き放った一方で、新たなリスクも生み出しました。
オンプレミス環境の時代には、セキュリティチームは物理サーバー、ネットワーク、およびアクセス権限を厳密に管理していました。しかし、クラウド環境では、その管理は共有されます。
エンジニアは数クリックでリソースを立ち上げることができ、ワークロードはリージョン、アカウント、さらにはプロバイダーをまたいで実行されます。このような民主化は強力ですが、同時に攻撃対象領域がこれまで以上に広がることを意味します。そして忘れてはならないのは、クラウドセキュリティは共有責任モデルに基づいているということです。
真の課題は、規模と複雑さという2つの点から生じます。もはや、単一の固定された環境を保護するだけではありません。大規模な環境では、毎分起動および停止する数百もの一時的なコンテナ、サーバーレス関数、およびサービスを保護することになります。
さて、コンプライアンス要件、マルチクラウド環境、そしてより迅速なリリースへの絶え間ないプレッシャーを重ねて考えると、クラウドセキュリティが重要であると同時に、正しく実装することが難しい理由が容易にわかります。
クラウドセキュリティガバナンスと責任のベストプラクティス
クラウドセキュリティにおいて、最大の敵の一つは混乱です。誰が何を所有しているか不明確だと、ギャップが生じ始めます。そのため、ガバナンスと責任は最初に取り組むべきベストプラクティスとなります。
1. クラウドプロバイダーを超えた共有責任モデルを理解する
共有責任モデルは万能ではありません。使用しているクラウド環境のタイプによって異なります。例えば、IaaSセットアップを運用する組織は、FaaS上で構築する生後6ヶ月のAIスタートアップよりもはるかに多くの責任を負います。
Center for Internet Security (CIS)による下の画像は、クラウド顧客が負う責任のレベルを示しています。
上記のイメージに加えて、セキュリティインシデントは単独で発生するものではないことを覚えておくことが重要です。つまり、クラウドセキュリティは「セキュリティチームだけの仕事」ではありません。エンジニアリング、運用、リーダーシップ全体にわたる共同の取り組みです。
そのことを念頭に置いて、どのようにすれば、この共有責任モデルを非難の応酬にすることなく受け入れることができるでしょうか？
その答えは…ドラムロール…「Shift Left」です。
ご想像の通りかもしれませんし、そうでないかもしれません。いずれにせよ、「Shift Left」は単なるバズワードではありません。開発者が記述するコード、インフラストラクチャ、そしてその間のすべてが潜在的な攻撃ベクトルであり、悪意のあるアクターにとっては何ら変わりはありません。
したがって、実行時のみセキュリティを心配するのではなく、コードの最初の行から心配し始めるべきです。
ソフトウェア開発ライフサイクル（SDLC）のどの段階でインシデントが発生した場合でも、SREの「非難しないポストモーテム」という考え方は、その失敗から学ぶのに役立ちます。
採用すべきベストプラクティス：
- クラウドプロバイダーの具体的な責任を学び、ご自身のクラウド環境における責任範囲を理解します。
- 開発者のワークフローに直接統合され、アンチパターン、脆弱な依存関係、バージョン管理システムに紛れ込むハードコードされたシークレットから保護する開発者ファーストのセキュリティツールを提供することで、セキュリティをシフトレフトします。
- 責任追及なしのポストモーテムの考え方を利用して、インシデントから学びましょう。
- Policy-as-Codeツールでガードレールを適用します。ご安心ください、これらの推奨事項については本記事の後半でさらに詳しく説明します。
2. セキュリティをコンプライアンス要件と統合する
ガバナンスについて語る上で、コンプライアンスは切り離せません。この2つは密接に関連しています。ガバナンスはルールを定め、コンプライアンスはそのルールが遵守されていることを確認します。
しかし、ここでの問題は、多くの組織がコンプライアンスを単なる書類作業として扱っていることです。おそらく、貴社もそうかもしれません。
監査に合格し、バッジを取得して次に進みます。
そのような考え方は危険です。GDPRやPCI DSSのようなコンプライアンスフレームワークは、単にクリアすべきハードルではありません。これらは機密データを保護し、リスクを軽減するために設計されたガードレールです。適切に実施すれば、ベースラインのセキュリティ体制が向上します。誤った方法で実施すれば、それは無駄な努力となります。
採用すべきベストプラクティス：
鍵となるのは、コンプライアンスを日常のワークフローに組み込むことです。インフラストラクチャを保護するために既に利用しているツールを使用します。一部のソリューションは、ISO 27001、SOC 2 Type 2、PCI、DORA、NIS2、HIPAAなどのコードおよびクラウドセキュリティ制御を自動化することで役立ちます。
クラウドセキュリティのアイデンティティとアクセス管理のベストプラクティス
すべてのガバナンスのベストプラクティスを網羅したところで、クラウドセキュリティの最も困難な側面の1つであるIDとアクセスの管理について見ていきましょう。
3. 最小権限の原則に従う
IDアクセスを効果的に管理するための最初のステップは、すべてのIDが必要なものだけにアクセスできるようにし、それ以上はアクセスさせないことです。これは最小権限の原則 (PoLP)が推奨することです。
PoLPは、API、サービスアカウント、コンテナ、サーバーレス関数などの非人間的なIDにも適用されるべきであることに注意することが重要です。これらは利便性のために過度に広範な権限で実行されることがよくあります。
侵害された場合、それらの権限は人間の管理者アカウントと全く同様に容易に悪用される可能性があります。人間とワークロードの両方にPoLP（最小権限の原則）を適用することで、潜在的な侵害の爆発半径を縮小できます。
採用すべきベストプラクティス：
- デフォルトでは「すべて拒否」とし、必要な最小限のアクションのみを許可します。
- ワイルドカード（s3:*）を明示的なアクション（例：s3:GetObject、s3:PutObject）に置き換えます。
- IAMロールおよびサービスアカウントから未使用の権限を定期的に監査し、削除してください。例えば、Lambda関数にAmazonS3FullAccessを付与する代わりに、以下のようなカスタムIAMポリシーをアタッチしてください。
{
"Version": "2012-10-17",
"Statement": [
{ "Effect": "Allow",
"Action": ["s3:GetObject", "s3:PutObject"],
"Resource": "arn:aws:s3:::my-app-bucket/*"
}
]
}これにより、関数が実際に必要とする1つのバケットにのみ読み書きでき、それ以外はできないことが保証されます。
4. 多要素認証（MFA）を利用する
各IDが必要なアクセス権のみを持つようにしても、特に管理者アカウントや重要なアカウントに対しては、多要素認証を実装することが依然として重要です。MFAは、認証情報に加えて2層目の保護を追加します。
今日のほとんどの多要素認証はメールベースの認証を使用しています。意図したとおりにセキュリティの追加レイヤーを提供しますが、フィッシングに対して脆弱です。
採用すべきベストプラクティス：
- MFAを実装する際、YubiKeyのような、フィッシングやその他のサイバー攻撃から防御するオプションを選択すべきです。これらのソリューションは物理キーベースのMFAを提供し、攻撃者は物理的にキーを盗む必要があります。
- シームレスな導入のために、ハードウェアキーをSSOプロバイダー（Okta、Azure AD、Google Workspace）と連携させます。
- リスクの高いアクション（例：本番環境へのアクセス、IAMポリシーの変更）に対して、多要素認証を要求します。
- ビジネスコンテキストの変化に応じて、すべてのアカウント（契約社員を含む）がMFA登録の対象となり、変更されていることを確認するために、MFA登録を定期的に監査してください。
5. ポリシーでRBACを超える
RBACと通常のIAMツールだけでは、クラウド、クラスター、コンテナ、またはコードレイヤーのいずれにおいても、クラウドネイティブ環境でのID管理の課題は解決しません。特にサービスアカウント、APIキー、証明書、シークレットなどの非人間IDの場合には、課題が残ります。
優れたクラウドネイティブのセキュリティプラクティスでは、特定のシナリオに合わせて調整された動的で詳細な権限を適用するために、Policy as Code (PaC)を使用することが求められます。
それらが連携して、階層型アクセス戦略を作成します。
- RBACは、誰が 何をするかを定義します。
- PaCは、いつ、どのように、そしてどのような特定の条件下で、を定義します。
例えば、Platform Adminロール (RBAC) を持つエンジニアはステージングにデプロイできます。しかし、イメージがスキャンされていない、ブランチが署名されていない、または営業時間外である場合、PaCルールはデプロイをブロックします。
この組み合わせにより、大規模な最小権限を強制し、誤操作を防ぎ、セキュリティを反復可能、テスト可能、監査可能にします。
採用すべきベストプラクティス：
AWSクラウドを使用している場合、そのエコシステムはプロアクティブ、予防的、検出的、および対応的なポリシー実装のためのツールを提供します。AWSでのPolicy as Code入門実践ガイドを読むことをお勧めします。
Azureのような他のクラウドサービスプロバイダーもPolicy as Codeツールを提供しています。また、プラットフォームに依存せず、デフォルトで「クラウドネイティブ」であるOpen Policy Agent (OPA)やKyvernoのようなオープンソースのPaCツールも検討できます。
6. キーと認証情報を定期的にローテーションする
人々は侵入があるまでキーの変更を待ちますが、そうすべきではありません。キーは定期的に自動でローテーションする必要があります。
「定期的に」とはどのくらいの頻度ですか？ 月次、四半期、または年次ですか？ CIS AWS Foundations Benchmarkは90日以内を推奨しています。
複雑な環境では、特に非人間系IDの場合、キーローテーションは「少ない方がより効果的」です。これらのキーをより頻繁に自動化することで、キーが侵害された場合の漏洩リスクを大幅に低減できます。これは、ほとんどの場合、これらの種類のIDにはほとんど可視性がないためです。
採用すべきベストプラクティス：
- 静的認証情報を短期間有効なトークン（例：AWS STS、GCP Workload Identity、Azure Managed Identities）に置き換えます。
- コードや設定ファイルではなく、一元的なマネージャー（AWS Secrets Manager、HashiCorp Vault、Azure Key Vault）を使用してシークレットを保存し、ローテーションします。
- ローテーション後の異常な認証情報使用がないか、ログ（CloudTrail、Audit Logs、Azure Monitor）を監視します。
- 未使用および公開されたキーを監査し、直ちに失効させます。ライブシークレット検出ツールは、アクティブなシークレットとその潜在的なリスクを特定するのに役立ちます。
7. Just-in-Time (JIT) アクセスを活用する
最小限のアクセス権を持つクラウドユーザーが、業務を遂行するために昇格された特権を必要とする場合があります。そのユーザーのデフォルトアクセスを昇格させる代わりに、永続的な権限ではなく、一時的な特権昇格を付与するためにJust-in-Time (JIT) アクセスを実装すべきです。
採用すべきベストプラクティス：
- 開発者は、必要な権限を持つロールを以下を伴って要求します:
- AWS上のOkta Access RequestsおよびAWS IAM Identity Center
- AzureにおけるJust-in-timeマシンアクセス
- Google Cloudまたはその他の外部ツールにおけるPrivileged Access Manager
- 昇格されたセッションには、常に時間制限（例：30分、1時間、1日）を設定してください。無期限の承認は避けてください。
- JITアクセスを許可する前に、MFA再認証を要求します。
- 監査可能性のために、すべてのJITリクエストと承認をログに記録し、監視してください。
クラウドセキュリティデータ保護のベストプラクティス
データはあらゆるビジネスの生命線です。実際、サーバー侵害とデータベース侵害の選択を迫られた場合、データベースよりもサーバーが選ばれることでしょう。それほどデータは価値があるのです。
では、クラウド上のデータをどのように保護するのでしょうか？
8. 転送中および保存時のデータ暗号化
保存時または転送時を問わず、クラウドデータは暗号化すべきです。保存データに対しては、AES-256やTDE (Transparent Data Encryption)のような強力で最新の暗号化アルゴリズムを使用してください。これにより、攻撃者が基盤となるストレージにアクセスできたとしても、必要な暗号化キーなしではデータが読み取れないことが保証されます。
転送中のデータについては、API呼び出しやサービス間トラフィックを含むすべての通信をTLS/SSLなどのプロトコルを使用して保護する必要があります。ゼロトラスト環境では、相互TLS (mTLS) を実装すべきです。これは、ネットワーク接続の両端にあるワークロード/IDが、それぞれ正しい秘密鍵を持っていることを検証することで、主張通りのものであることを保証するためです。
クラウドデータ暗号化は、強力なキー管理システム (KMS) に依存します。KMSは、暗号化キーの生成、保存、管理、ローテーションを行うための安全で一元化されたサービスであるべきです。
採用すべきベストプラクティス：
- すべてのストレージボリューム、データベース、オブジェクトストレージ（例：AWS S3 SSE、Azure Storage Service Encryption、GCP CMEK）を暗号化します。
- すべてのAPIエンドポイントおよびサービス間トラフィックに対してTLS 1.2以降を強制する。
- 内部マイクロサービスにmTLSを実装し、なりすましを防止します。
- マネージドKMS（AWS KMS、Azure Key Vault、GCP KMS、HashiCorp Vault）でキー管理を一元化します。
- キーローテーションを自動化し、不正なキー使用を監視します。
以下のKubernetes Ingressスニペットは、クライアントがサービスにアクセスする前に、信頼されたCA（client-ca）からの有効な証明書を提示することを要求することでmTLSを強制します。
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: app-ingress-mtls
annotations:
kubernetes.io/ingress.class: nginx
nginx.ingress.kubernetes.io/auth-tls-secret: "prod/client-ca" # client CA cert
nginx.ingress.kubernetes.io/auth-tls-verify-client: "on" # require client cert
spec:
tls:
- hosts:
- secure.example.com
secretName: secure-app-tls
rules:
- host: secure.example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: app
port:
number: 80
9. データのバックアップと復旧テスト
データのバックアップを取るための主要な2つの黄金律があります。3-2-1ルールと3-2-1-1-0ルールです。
3-2-1は以下を推奨します:
- 3 = データを3つのコピーで保持する
- 2 = 2種類の異なるストレージメディアを利用する
- 1 = 1つのコピーをオフサイトに保存
3-2-1-1-0は3-2-1を基盤とし、現代の脅威から保護するために、以下を推奨します:
- 3 = データを3つのコピーで保持する
- 2 = 2種類の異なるストレージメディアを利用する
- 1 = 1つのコピーをオフサイトに保存
- 1 = 1つのコピーをオフラインまたは不変で保存
- 0 = バックアップエラーゼロを保証
重要なのはバックアップを取っているかどうかではなく、そのバックアップで復旧できるかどうかです。多くのチームは、災害が発生するまでバックアップは安全だと考えていますが、いざという時にファイルが破損していたり、データが失われていたり、復旧プロセスに数時間ではなく数日かかることが判明したりします。
すべてが順調に稼働しているときにバックアップのテストは不要に感じるかもしれませんが、障害は予定通りには発生しません。
大規模な障害発生時、テスト済みのバックアップと未テストのバックアップがある状況で復旧を試みる際の、心拍数が高まるような状況を想像してみてください。
採用すべきベストプラクティス：
- バックアップを保存時および転送時に暗号化します。
- 定期的なリカバリ訓練を実施し、目標復旧時点 (RPO) および目標復旧時間 (RTO) を確立し、検証します。
- プレッシャーの下でも実行できるように、リカバリ手順を文書化します。
- 古いバックアップをローテーションしてクリーンアップし、攻撃対象領域とコストを削減します。
準備は完了です！
10. 機密データを分類およびラベル付けする
把握していないものを保護することはできません。ほとんどのクラウド環境では、機密データがS3バケット、データベース、メッセージキュー、さらにはログにまで分散しています。適切な分類がなければ、適切な制御を適用することは不可能です。
機密性に基づいてデータをタグ付けおよびラベリングすることで（公開、社内、機密、制限）、可視性を高め、拡張可能なガードレールを適用できます。
多くのクラウドプロバイダーは、組み込みの分類ツール（例：AWS Macie、Azure Information Protection、GCP DLP）をサポートしています。データがラベル付けされると、暗号化、アクセス制限、監視を自動的に適用できます。
採用すべきベストプラクティス：
- ストレージバケットとデータベースをスキャンし、PII、認証情報、財務データを検出します。
- メタデータタグまたはラベル（例：sensitivity=confidential）を適用して、ポリシーをトリガーします。
- クラウドネイティブツールまたはサードパーティスキャナーで分類を自動化します。
- 「制限された」データクラスへのアクセスを、承認されたロールのみに制限します。
11. トークン化と匿名化を適用する
データを保護するということは、漏洩しても無意味になるように変換することを意味する場合があります。トークン化は、機密性の高いフィールド（クレジットカード番号など）を非機密性のプレースホルダーに置き換え、匿名化はデータセットから識別情報を完全に削除します。どちらのアプローチも、ビジネスワークフローを停止することなく露出を減らします。
これらの手法は、開発者、アナリスト、または第三者が生の機密値を見ることなくデータセットにアクセスする必要がある環境において、特に重要です。適切に実施すれば、トークン化と匿名化により、セキュリティとユーザビリティのバランスを取ることができます。
採用すべきベストプラクティス：
- 支払い情報を保存する前にトークン化します。PCI準拠のボールトを使用できます。
- PII（例：氏名、メールアドレス）をマスキングすることで、分析データセットに匿名化を適用します。
- システムがデータフォーマットを検証できるように、フォーマット保持トークン化を使用してください。
- インジェストポイントでの変換を自動化し、生データがログや非セキュアなシステムに決して入らないようにします。
クラウドセキュリティのネットワークとインフラストラクチャのベストプラクティス
安全で信頼性の高いシステムを構築するには、組織はクラウド環境の基盤を強化する必要があります。これは、ネットワーク設計、接続性、およびインフラストラクチャ管理におけるベストプラクティスを採用することを意味します。
その方法は次のとおりです。
12. ネットワークセグメンテーションを実装する
フラットなネットワークは脆弱です。クラウド内のすべてのリソースが同じネットワーク上にある場合、1つのリソースが侵害されると、攻撃者はクラウド全体を自由に動き回ることができます。これが、クラウドセキュリティ戦略のためにネットワークセグメンテーションを実装すべき理由です。
採用すべきベストプラクティス：
目標はマイクロセグメンテーションです。ワークロードをその機密性と機能に基づいて分離することで、すべての接続が潜在的な脅威として扱われるゼロトラストを強制します。これは、ネットワークセキュリティグループ、プライベートVLAN、内部ファイアウォールなどのツールを使用して実現できます。
上記のネットワークセグメンテーションの図では、FRONTENDおよびMIDDLEWAREセグメントにはインターネットアクセスがありますが、異なる情報システムのFRONTENDセグメントとMIDDLEWAREセグメント間のアクセスは禁止されています。
この基盤レイヤーは、MIDDLEWARE 1で設定ミスや脆弱性がエクスプロイトされたとしても、影響範囲が最小限に抑えられ、他のMIDDLEWAREが保護されることを保証します。
13. APIエンドポイントの保護
APIは、クラウドアプリケーションの神経系です。そして、生物（この場合はアプリケーション）を破壊する最も速い方法は、その神経系を攻撃することです。
環境内のすべてのAPIが適切な認証および認可メカニズムを備えていることを確認することが最優先事項です。これにより、脅威アクターがそれらをエクスプロイトして不正アクセスを取得したり、サービスを妨害したりすることを防ぎます。
採用すべきベストプラクティス：
- すべての外部APIを、ルートごとのポリシーを持つゲートウェイ（Kong/Apigee/AWS API Gateway）の背後に配置します。
- OAuth2/OIDCを要求し、短期間で最小権限のスコープを発行します（ワイルドカードクレームなし）。
- APIキー/クライアントごとにレート制限/クォータを適用し、高コストなルートにはより厳格な制限を設けます。
- すべての場所でTLS 1.2以降を有効にし、内部マイクロサービス呼び出しにはmTLSを使用します。
- APIを自動検出してタグ付けし、ドキュメント化されていないバージョンや非推奨のバージョンをブロックまたは廃止します。
- APIログをSIEMに送信し、401/403の急増、異常なデータプル、または列挙パターンをアラートします。
- そして、脆弱性や欠陥がないかAPIを継続的にスキャンすることを忘れないでください。
前述の通り、APIセキュリティはクラウドセキュリティ戦略の核となります。さらなるガイダンスや実践的なチュートリアルについては、他のブログ記事をご覧ください。
14. コンテナを保護する
すべての組織がクラウドネイティブ化のメリットを望んでいます。しかし、その課題にも対応する準備はできていますか？
コンテナはクラウドネイティブインフラストラクチャの基盤ですが、独自のリスクも伴います。設定ミス、脆弱なベースイメージ、過剰な特権はすべて、攻撃者への扉を開く可能性があります。
ほとんどのコンテナセキュリティリスクと問題は、推奨されるベストプラクティスに従うことで対処できる点が良いことです。
採用すべきベストプラクティス：
- 信頼できるソースから、最小限で検証済みのベースイメージ（例：distroless、Alpine）を常に使用してください。特定のイメージバージョンを使用してください。
- 不要なLinuxケーパビリティを削除します（CAP_SYS_ADMINはほぼ常に危険信号です）。
- コンテナをrootとして実行しないでください。エッジケースでコンテナがrootアクセスを必要とする場合、コンテナのUIDをホスト上のより権限の低いユーザーに再マッピングしてください。
- ランタイムアクティビティを監視し、異常な動作をリアルタイムで検出して対応します。
- イメージとそのリポジトリを自動的にスキャンし、ベースイメージとDockerfileで使用されているオープンソースパッケージ内の脆弱性を発見し修正します。
コンテナのオーケストレーションにKubernetesを使用している場合、デプロイメントなどのAPIサーバーへのリクエストをインターセプトし、デプロイ前に特定のセキュリティ条件が満たされていることを検証するために、アドミッションコントローラーを設定できます。
15. 安全な構成ベースラインを採用する
デフォルト設定は利便性のために構築されており、安全性のためではありません。インフラストラクチャを安全に保つには、OS、コンテナランタイム、クラウドサービスを厳格なベースラインでロックダウンし、スプリントごとに強化策を再考する必要がないようにします。
採用すべきベストプラクティス：
- CISベンチマーク（特定のOS、Kubernetes、Docker、クラウドプロバイダー向け）から始め、それらをコードのように扱います。つまり、バージョン管理され、レビューされ、Infrastructure as Code (IaC) を介して強制されるようにします。
- 以前に強調したPolicy-as-Code（OPA、Kyrveno、Terraform Sentinel、Azure/AWS/GCP Policy）で設定を適用します。
- セキュアなデフォルト設定を有効にします：SSHの強化、auditd、カーネルパラメータ、ルート権限なしコンテナ、読み取り専用ファイルシステム。
上記すべてを設定することで、すべてのクラウドにおける設定ミス、露出、ポリシー違反を継続的に検出し、それらを迅速に修正します。
16. ソフトウェアアップデートとセキュリティパッチを定期的に適用する
率直に言って、パッチ未適用は脆弱性を意味します。
一般的な推奨事項は、インフラストラクチャ内のすべてのリソースが安定したバージョンに更新され、パッチが適用されていることを確認することです。
しかし、数百ものサービスやツールがある中で、それを大規模にどうやって行うのでしょうか？
ここで、Human-in-the-loop AI がインフラストラクチャの可視性を高め、問題を自動修正するためにその真価を発揮します。
採用すべきベストプラクティス：
- 対応が必要な問題に対してチケットを自動作成できるツールを活用し、SBOMの生成と追跡を行います。
- セキュリティ研究者によって検証されたCVEフィードをサブスクライブして、最新のサプライチェーンの脅威に関する情報を常に把握してください。
- パッチ適用済みのベースイメージから毎週イメージを再構築し、タグではなくダイジェストを固定してください。
- メンテナンスウィンドウとカナリアリリースを使用してください。エラー率を測定し、迅速にロールバックしてください。
- マネージドサービスは、サポートされているエンジンバージョン（DB、ランタイム、ゲートウェイ）で運用してください。
17. Web Application Firewall (WAF)とDDoS防御を導入する
WAFは不要なトラフィックをフィルタリングし、DDoSシールドはトラフィックが敵対的になった場合でもオンライン状態を維持します。これらをAPIやアプリケーションの前に配置することで、SQLiやXSSをブロックし、L7フラッドを抑制できます。さらに、レート制限やボット制御と組み合わせることで、シグネチャをすり抜けるグレーゾーンの悪用に対処できます。
上記のネットワークセグメンテーションの図を思い出していただければ、フロントエンドロードバランサーとウェブサーバーの間にWAFが存在します。
採用すべきベストプラクティス：
- チューニングされたルールセット（OWASP CRS + カスタム）を使用して、WAF（Aikido Zen/AWS WAF/Azure WAF/Cloud Armor）をデプロイします。
- 自動緩和機能によりDDoS防御を有効にします。
- JSONボディ（APIモード）を検査し、スキーマを検証し、すべてのブロックをSIEMにログ記録します。
- カオスドリルを実行してスパイクをシミュレートし、オートスケーリングとWAF/DDoSポリシーが効果的であることを確認します。
クラウドセキュリティの脅威検出と監視のベストプラクティス
脅威を迅速に検出して対応することは、クラウドにおけるセキュリティインシデントの影響を軽減するために不可欠です。そのため、プロアクティブな監視と検出のベストプラクティスは、クラウドセキュリティの重要な要素となります。
18. 高度な監視およびログツールを導入する
ログは早期警告システムです。ただし、実際にそれらを一元化して分析した場合に限ります。
クラウドでは、APIコール、VMアクティビティ、Kubernetes監査ログ、ネットワークフローデータなど、イベントがサービス全体に分散します。
それらをSIEMまたはデータレイクに集約し、その後、Grafanaのようなオープンソースの可視化ツールとアラートでダッシュボードを構築し、何も見落とされないようにします。
採用すべきベストプラクティス：
- AWS CloudTrail、GuardDuty、VPC Flow Logs、Azure Monitor、GCP Cloud Audit Logsなどのサービスで、クラウドネイティブなロギングを有効にします。
- ログを相関分析のために一元化された場所にストリームします。統合されたロギングレイヤーを構築するために、データコレクターを使用できますし、使用すべきです。最も堅牢なものの一つは Fluentdです。これはオープンソースであり、コアをシンプルに保ちながら、データソースと出力を接続するための500以上のプラグインを持っています。
- それが完了したら、高リスクなアクション（IAMの変更、新しい公開バケット、特権昇格）に対するアラートを定義します。
- コンプライアンスおよびフォレンジックの要件を満たすログ保持ポリシーを設定します。
19. 脆弱性評価のための依存関係グラフの使用
このガイドの冒頭から、脆弱性を自動的に発見することについて述べてきました。ただし、すべての脆弱性が修正する価値があるわけではないことも重要です。重要なのは、実際にデプロイされた環境でリスクをもたらす脆弱性がどれであるかを知ることです。
ここで依存関係グラフが不可欠になります。それがなければ、重要でないCVEに溺れ、本当に重要なものを見逃してしまうでしょう。
採用すべきベストプラクティス：
- 誤検知を排除し、エクスプロイト可能な脆弱性のみを特定するために、到達可能性分析を提供するプラットフォームを使用してください。
- 開発/テスト専用の依存関係は無視し、本番環境にデプロイされるものに焦点を当ててください。
- 到達可能でインターネットに公開されているCVEに優先順位を付けます。
- コード、コンテナ、クラウド構成全体で脆弱性を関連付けます
20. バイブコーディングに注意する
バイブコーディングは、今最も注目されている新しいものです。
デザイナー、マーケター、営業担当者、あるいは誰もが、自分で多くのコードを書かずにアプリや機能を立ち上げられるようになりました。これは多くの場合、テスト、レビュー、またはセキュリティの考慮なしに行われることを意味します。それは高速で、摩擦がなく、魔法のように感じられます。しかし、ガードレールなしの魔法は燃え尽きがちです。
より安全に「コードを評価する」には、採用すべきベストプラクティスは次のとおりです。
- AIが生成したコードやエンジニア以外が出荷したコードは、ジュニア開発者が書いたものとして扱います。常にコードレビューを実施し、複数の目で確認しましょう。
- 独自の認証、入力検証、またはシークレット管理を実装しないでください。十分にレビューされ、監査されたライブラリまたはサービスを使用してください。
- シークレットをフロントエンドやリポジトリから除外し、安全なストレージと環境管理を使用してください。
- デプロイ前に、vibe-codedアプリに対してスキャン（依存関係、SAST、DAST）を自動化してください。パイプラインで容易な脆弱性を検出させましょう。
より実践的な手順を知りたいですか？弊社の Vibe Coders’ Security Checklistをご覧ください。
21. CI/CDにおける継続的なペンテスト
継続的なペンテストは、定期的なセキュリティチェックの概念を覆し、自動テストをビルドおよびデプロイパイプラインに組み込むことで、脆弱性が本番環境に到達する前に検出されるようにします。これは、スピード、コンテキスト、そしてよりクリーンなフィードバックループに関するものです。
採用すべきベストプラクティス：
- すべてのプルリクエストでSASTとシークレットスキャンをセットアップします。
- デプロイ前にCIでIaCスキャン（Terraformスクリプト、CloudFormation、Helmをスキャン）を実行します。
- 高/重大度脆弱性に対してビルドを失敗させ、中程度の検出結果はダッシュボードでバックログとしてフラグ付けします。
- 各種類の検出結果（コード、インフラ、クラウド）に対し、文書化されたSLAを持つチームまたは個人の「オーナー」を配置してください。
- 検出結果、誤検知をレビューし、ツールを調整するために、定期的に「ペンテストの振り返り」を実施します。
クラウドセキュリティの運用とレジリエンスのベストプラクティス
クラウドセキュリティは予防だけではありません。混乱に備え、事業継続性を確保することも必要であり、そのためには運用上の卓越性とレジリエンスの実践が重要です。
22. インシデント対応計画の策定
「計画しなければ、失敗を計画しているようなものだ」という決まり文句をご存知でしょうか。これはセキュリティの世界でも同様です。
インシデントは必ず発生します。重要なのは、インシデント発生時にどのように対応し、事後に何を行うかです。
強固なインシデント対応計画を構築する上で重要な要素は何ですか？
- インシデントと見なされるもの（データ漏洩、マルウェアによるサービス停止など）について、明確な線引きをする必要があります。それがなければ、常に混乱が生じます。
- 開発者、テックリード、広報、法務など、誰が何をするのかを明確にします。また、バックアップ担当者も記載してください。
- 内部と外部。誰が知る必要がありますか？いつ？そしてどのように？
- 段階的なフローを策定します：検出 → 評価 → 封じ込め → 根絶 → 復旧 → 教訓。インシデントがエスカレートされる前にどの程度の深刻さであるべきかの基準（深刻度ティア）を含めます。
- ログを保存する必要がある場合、システムを隔離する場合、または外部の支援が必要な場合、計画には証拠を保全する方法を含めるべきです。
- 計画を確認し、ギャップを特定するため、少なくとも年に一度、テーブルトップ演習またはシミュレーション演習を実施します。
23. ゼロトラストセキュリティモデルの実施
これまでのところ、このガイドではゼロトラストについて何度か言及してきました。ゼロトラストは購入する製品ではなく、考え方です。決して信頼せず、常に検証する。ネットワークがフラットで、IDが新たな境界となるクラウド環境では、このモデルはこれまで以上に重要です。
環境内のユーザーやサービスが安全であると仮定する代わりに、ゼロトラストは人間またはマシンからのすべてのリクエストに、自身の正当性を証明することを強制します。これは、強力な認証、最小権限の認可、暗号化された接続、および継続的な検証を意味します。攻撃者が侵入した場合でも、ゼロトラストは横方向の移動を阻止します。
導入すべきベストプラクティス：
- すべてのユーザーとワークロードに対して、MFAと強力なIDチェックを要求します。
- きめ細かいRBAC/ABACポリシーで最小権限を適用します。
- マシン間トラフィックを検証するために、ネットワークマイクロセグメンテーションとSPIFFE/SPIREなどのサービスIDを使用してください。
- 「信頼された」VPCやクラスター内であっても、すべてのトラフィックをTLS/mTLSで暗号化します。
- 行動を継続的に監視し、異常が検出された場合はセッションを失効させます。
24. クラウドアクセスセキュリティブローカー (CASB) の活用
平均的な組織は、通常、正当な理由で多くのSaaSアプリを使用しています。迅速な行動が求められる際、貴重なエンジニアリング時間を車輪の再発明に費やしたくはありません。課題は、それらの多くがセキュリティ監視なしに導入され（シャドーIT）、盲点を作り出していることです。
A Cloud Access Security Broker (CASB)は、中央のチェックポイントを提供し、どのアプリが使用されているか、どのようなデータがそれらを介して流れているか、そして使用状況がポリシーに準拠しているかについての可視性をもたらします。
CASBはSaaS環境全体で制御を適用します。対策には、機密データが個人ドライブにアップロードされるのを防ぐこと、ファイル共有に暗号化を要求すること、危険な場所からのログインをブロックすることなどが含まれます。これらは、ユーザー、SaaSアプリケーション、既存のIAMおよびDLPポリシー間のセキュリティの「接着剤」として機能します。
採用すべきベストプラクティス：
- 組織全体のSaaS利用状況を監視するために、CASBをプロキシモードまたはAPIモードでデプロイします。
- 不正なアプリを検出し、リスクのあるものをブロックすることで、シャドーITを特定します。
- 機密データが承認済みアプリから流出するのを防ぐDLPポリシーを適用します。
- SaaSアクセスを許可する前に、コンテキストアウェアなアクセス（デバイスの状態、地理的位置、リスクスコア）を要求します。
- インシデント検出と自動応答のために、CASBをSIEM/SOARと連携させます。
25. 強固なセキュリティ意識文化の醸成
本記事で取り上げたこれらのベストプラクティスは、それらを実装し遵守すべき人間が怠れば無意味になります。「鎖は最も弱い環と同じくらいしか強くない」という格言は、組織内の個人にも当てはまります。
目標の反復に費やせる貴重な時間を奪う強制的なセミナーでチームを退屈させたくない一方で、セキュリティ体制を常に評価し、チームがセキュリティ意識を持つことの影響を理解していることを確認するバランスを取ることも重要です。
採用すべきベストプラクティス：
- 継続的なトレーニング、フィッシングシミュレーション、および安全な行動への報奨。
- コードレビューにセキュリティを組み込みましょう。バグだけでなく、ハードコードされたシークレット、過剰な権限を持つAPIコール、公開されたエンドポイントも確認します。
- 最も多くの脆弱性を発見した者にはリーダーボードを設け、セキュリティ問題の報告には報酬を与えることで、セキュリティ意識向上をゲーミフィケーション化します。
- セキュリティインシデントに対する非難なしの事後検証。正直なミスで解雇されると、次回からはより巧妙に隠すようになるでしょう。
- 脅威モデリングセッションにより、開発者はコード出荷後ではなく、設計フェーズ中に攻撃者のように考えるようになります。
シフトレフトで先行し、自信を持ってリリースしましょう。
これらすべてを述べた上で、セキュリティが目的地ではなく旅のようなものであることを理解することが重要です。数年前、Aikidoの私たちに「vibe coding security」という言葉が同じ文脈で使われると話したら、驚きの目で見られたことでしょう。しかし、私たちは適応し、セキュリティ侵害でトップページに載ることがないよう、積極的な措置を講じています。
これが、私たちがAikidoを構築した本質的な理由です。シフトレフトを支援し、設定ミスを早期に発見し、安全性を犠牲にすることなく開発者が迅速に作業を進められるようにするためです。
ここで疑問に思われるかもしれません。「では、どのように始めればよいのでしょうか？」
答えは、すでに実行しているということです。これらのベストプラクティスを読み、より強力なクラウドセキュリティに向けて対策を講じることで。次のステップは簡単です。当社のチームとデモを予約し、Aikidoがいかに重労働を軽減し、最も重要なこと、つまり自信を持ってリリースすることに集中できるかをご覧ください！
クラウドセキュリティに関するシリーズ記事をさらに読む:
クラウドセキュリティ: 完全ガイド
クラウドアプリケーションセキュリティ: SaaSおよびカスタムクラウドアプリの保護
クラウドセキュリティツール＆プラットフォーム: 2025年比較
