クラウドセキュリティのヒントは、攻撃者が悪用する実際の脆弱性に対処する場合にのみ役立ちます。例えば、誰も気づかなかった公開S3バケットや、ワイルドカードを使用したCIランナーなどです。 AWS 権限、ビルドログに漏洩した秘密情報、またはビルド中に静かにインストールされた悪意のある依存関係 pipeline 実行してください。クラウドセキュリティインシデントのほとんどは、未知の脅威によって引き起こされるものではありません。それらは、これまで対策が講じられず、優先順位が付けられず、修正もされなかった既知の脆弱性によって引き起こされます。
このガイドでは、ID、データ、インフラストラクチャ、ソフトウェアサプライチェーン、 CI/CD pipeline検出とインシデント対応。単一のクラウドアカウントを強化する場合でも、複数チームのセキュリティを確保する場合でも。 DevSecOps pipelineこれらの対策は、実際に発生する侵害を防止するのに役立ちます。
数多くのクラウドセキュリティ対策があるにもかかわらず、クラウドセキュリティが失敗し続ける理由
クラウドセキュリティとは、クラウド環境で実行されるデータ、アプリケーション、インフラストラクチャを保護するための制御、ポリシー、ツールの集合体です。これは、ID、ネットワーク、データ、アプリケーションコード、依存関係、インフラストラクチャ構成、構築など、幅広い範囲をカバーします。 pipelines.
成熟したチームでさえ失敗し続ける理由は、知識不足ではない。構造的な問題が3つあるのだ。
- スピードか、それともセキュリティか。 Pipeline迅速に行動する。摩擦を生むような制御は無効化される。クラウドセキュリティを正しく理解しているチームは、ゲートを追加するのではなく、ワークフローに直接、自動化された強制適用機能を導入する。
- ツールの断片化。 1つのツールで秘密情報をスキャン、 SCA 別の例では、 IaC 3つ目の問題点は、統一された見解がないために、カバレッジ層間にギャップが生じ、調査結果が実際のリスクと関連付けられないことである。
- 警戒疲労。 1日に数百件ものCVE(共通脆弱性識別子)を検出するスキャナーは、エンジニアに重大なものも含め、検出された脆弱性を無視するよう訓練してしまう。優先順位付けは選択肢ではなく、セキュリティが実際に機能するかどうかを決定づける重要な要素なのだ。
以下のクラウドセキュリティに関するヒントは、これらのギャップを実践的な方法で埋めることを目的としています。クラウドセキュリティをランタイムのみの問題として扱うのではなく、コードからクラウドへの配信パス全体を網羅しています。
クラウドセキュリティに関する20のヒント:
IDおよびアクセス管理のクラウドセキュリティに関するヒント
1. あらゆる場所で多要素認証を有効にする
多要素認証(MFA)は、クラウドセキュリティにおいて依然として最も高い投資対効果(ROI)をもたらす対策です。MFAは認証情報窃盗攻撃を完全に阻止し、攻撃者もそのことをよく理解しています。MFAが設定されていないアカウントは、攻撃の格好の標的となります。
クラウド環境内のすべての人間のIDに対してMFAを強制します: 開発者アカウント、管理コンソール、クラウドプロバイダーポータル、 CI/CD dashboard特権アカウントには、フィッシング対策に優れた多要素認証(ハードウェアキー、パスキーなど)を使用してください。認証アプリによる時間ベースの認証コードは最低限の基準です。
2. 最小特権の原則を適用する(特に非人間的なアイデンティティに対して)
最小権限の原則 人間についてはよく理解されている。チームが常に見落としているのは、人間以外のアイデンティティだ。 CI/CD サービスアカウント、Lambda関数、コンテナワークロード、GitHub Actionsランナー。
これらのIDは一度設定されると二度と変更されないため、ワイルドカード権限が蓄積されます。また、機密情報、リポジトリ、本番環境のリソース、下流システムへのアクセス権を持つため、サプライチェーン攻撃において攻撃者がまさに標的とする対象となります。
// Bad: wildcard S3 permissions on a Lambda function { "Action": "s3:*", "Resource": "*" } // Good: scoped to exactly what the function needs { "Action": ["s3:GetObject", "s3:PutObject"], "Resource": "arn:aws:s3:::my-app-bucket/uploads/*" } サービスアカウントの権限を四半期ごとに監査し、90日間使用されていない権限はすべて削除してください。
3. 有効期限の長い認証情報を有効期限の短いトークンに置き換える
静的なAPIキーと有効期限の長いトークンは、クラウド侵害の最も一般的な根本原因の1つです。 commitリポジトリにコピーされ、CI ログに漏洩し、Slack にコピーされ、忘れ去られた .env ファイルはその後、数ヶ月または数年間有効なままになります。
可能な限り、有効期限の短い認証情報に置き換えてください。 AWS STS ロールの引き受け, GCPワークロードIDフェデレーション, GitHub Actions OIDC静的認証情報が避けられない場合は、シークレットマネージャー(Vault、AWS Secrets Manager、Azure Key Vaultなど)に保存し、自動的にローテーションしてください。
4. 特権昇格のためのジャストインタイムアクセスを実装する
常時管理者権限を持つことは、常時リスクとなる。永続的に高い権限が付与されているということは、たった1つのIDが侵害されるだけで、本番環境に影響が及ぶ可能性があることを意味する。
JITアクセスシステム(AWS IAM Identity Center、GCP Privileged Access Manager、Okta Access Requestsなど)は、オンデマンドで、時間制限付きで、完全な監査ログ付きで、高度なアクセス権限を付与します。開発者は必要な時に必要なものを入手できます。攻撃者は、常に攻撃の標的となる場所を見つけることができません。
5. サービス間通信全体にゼロトラストを適用する
従来の境界型セキュリティモデルでは、ネットワーク内部のすべてが信頼できるものと想定されています。しかし、マイクロサービス、コンテナ、動的なワークロードを備えたクラウドネイティブ環境では、この想定は危険です。
ゼロトラスト これは、リクエストの発信元に関わらず、すべてのリクエストが認証および認可されることを意味します。サービス間認証(mTLS、サービスメッシュID)を実装し、ワークロードレベルでネットワークポリシーを適用し、内部トラフィックをデフォルトで信頼できないものとして扱います。
データ保護クラウドセキュリティのヒント
6. 内部通信も含め、すべてを暗号化する
保存時の暗号化(AES-256(マネージドKMS)は現在 standard 練習。ほとんどのチームが抱えているギャップは 内部トラフィックの転送中の暗号化.
マイクロサービスとコンテナ間通信を含むVPCでは、「内部」にとどまるトラフィックは必ずしも安全ではありません。内部サービス間の通信には相互TLS(mTLS)を実装してください。各チームが適切に設定するのではなく、サービスメッシュ(Istio、Linkerdなど)またはゼロトラストネットワークレイヤーを使用して、これを自動的に強制するようにしてください。
7. 漏洩した機密情報が拡散する前に検知し、修復する
秘密 commitリポジトリに追加された情報は、秘密のままではいられません。GitHub は公開リポジトリを数秒以内にインデックス化します。内部リポジトリも例外ではなく、一度秘密情報が Git の履歴に記録されると、現在または将来、リポジトリへのアクセス権を持つ人なら誰でもアクセスできるようになります。
予防層が重要(pre-commit hooksIDEプラグインなど)はありますが、それだけでは不十分です。履歴を含むすべてのリポジトリを継続的にスキャンする必要があります。 commits, CI/CD ログ、 IaC ファイル、およびコンテナイメージ。秘密情報が検出された場合は、即座に対応する必要があります。具体的には、情報の取り消し、ローテーションを行い、漏洩から検出までの間にアクセスがあったかどうかを評価する必要があります。
8. データの分類と機密性に基づく制御の適用
クラウド環境内のすべてのデータが、漏洩した場合に同じリスクを伴うわけではありません。すべてを同じように扱うと、リスクの低いデータへの対策に過剰な投資を行い、本当に重要なデータの保護がおろそかになってしまいます。
データの機密性(公開、内部、機密、制限付き)に基づいてデータを分類する。アクセス制御と暗号化を適用する。 standard各階層ごとに、監査ログ要件を定めます。可能な限り分類を自動化し、手動タグ付けは拡張性に欠けます。
インフラストラクチャと構成のセキュリティ
9.スキャン IaC 毎日 Commit展開直前ではない
インフラストラクチャ・アズ・コードは、本番環境ではなく、設定ミスが発生する場所です。パブリックS3バケット、オープンセキュリティグループ、またはIAMロール *:* パーミッションは偶然発生するものではありません。それは、誰も気づかなかったTerraformファイルやKubernetesマニフェスト内の行として始まります。
IaC スキャンは毎回実行する必要があります pull requestコードレビューワークフローで発見された内容に基づいて、Terraform、Kubernetesマニフェスト、CloudFormation、Helmチャート、Dockerfile、および CI/CD 設定。
# This fails immediately in Xygeni IaC scanning: resource "aws_s3_bucket" "data" { bucket = "company-data" acl = "public-read" # ← flagged: public access enabled } ザイゲニ IaC Security あらゆるサポートされているフォーマットをスキャンします commit調査結果を特定のリソースにマッピングし、PRワークフローと統合することで、開発者は別の場所ではなく、作業現場でフィードバックを受け取ることができます。 dashboard 決して開かない。 無料トライアルを開始 →
10. セキュリティポリシーをコードとして扱う
手動によるセキュリティレビューは拡張性に欠ける。ポリシー・アズ・コードは拡張性に優れている。
OPA(Open Policy Agent)やKyvernoなどのツールを使用して、セキュリティルールをバージョン管理されたテスト可能なコードとして表現します。それらを適用するには、 pipeline レベルなので、Kubernetes デプロイメントは 特権:true あるいは、root権限で実行されているコンテナは、毎回自動的にビルドに失敗します。ポリシーがコード内に存在する場合、他のエンジニアリング成果物と同様にレビューされ、改善されます。しかし、ドキュメント内に存在すると、ポリシーは曖昧になってしまいます。
11. セキュアな構成ベースラインを適用し、逸脱を監視する
デフォルト設定は利便性を重視して最適化されており、セキュリティは考慮されていません。クラウドサービス、コンテナランタイム、マネージドKubernetesクラスターは、使いやすく、かつ悪用されやすい設定で出荷されます。
から開始します CIS クラウドプロバイダー、コンテナランタイム、OSのベンチマークを設定します。これらをポリシー・アズ・コードとしてエンコードすることで、自動的に適用されます。設定のずれを継続的に監視します。先週準拠していた構成が、プレッシャーの中で急激な変更を加えた結果、今日は準拠していない可能性があります。
12. ネットワークをセグメント化し、横方向の移動を制限する
フラットなネットワークアーキテクチャでは、攻撃者が一度一つのワークロードを侵害すると、他のすべてのワークロードにもアクセスできてしまう。ネットワークセグメンテーションは、被害範囲を限定する。
VPC、サブネット、セキュリティグループを使用して、機能と機密性に基づいて分離ゾーンを作成します。サービス間の東西トラフィックを必要なものだけに制限します。送信フィルタリングを実装します。侵害されたワークロードのほとんどは攻撃者が制御するサーバーに到達する必要があり、送信制御はそれを検知または防止するための最良の機会の1つです。
ソフトウェアサプライチェーンのクラウドセキュリティに関するヒント
最も重要なクラウドセキュリティのヒントのいくつかは、もはやクラウドプロバイダーのコンソール内から始まるものではありません。それらは、ソフトウェアサプライチェーンのより早い段階から始まります。依存関係、 CI/CD ワークフロー、シークレット、ビルドスクリプト、および成果物はすべて、デプロイ前にクラウドリスクをもたらす可能性があります。
13. ビルドに入る前にすべての依存関係をスキャンする
オープンソースパッケージは、現代のサプライチェーン攻撃において最も一般的な初期アクセス経路となっている。2024年のShai-Hulud攻撃では、830以上のnpmパッケージが侵害された。XZ Utilsのバックドアは、数百万台のLinuxシステムにわたるSSH認証をほぼ完全に侵害した。どちらのケースでも、悪意のあるコードは通常の依存関係のインストールプロセスを通じて侵入した。
Basic SCA (ソフトウェア構成分析)の生のCVEリストだけでは不十分です。実際に必要なのは次のものです。
- 到達可能性分析: 脆弱性のある関数は、実際にあなたのコード内で呼び出されていますか?
- マルウェアの検出このパッケージは悪意のある動作、難読化されたスクリプト、予期しないネットワーク呼び出し、ライフサイクルを示しますか? hooks 外部ランタイムをインストールするのですか?
- EPSSスコアこのCVEが理論上だけでなく、実際に現在悪用されている可能性はどれくらいありますか?
14. ロックダウン CI/CD Pipelines
CI/CD これらのシステムは、機密情報、クラウド認証情報、および本番環境にアクセスできます。また、通常、デプロイ先の本番システムよりもセキュリティ対策が不十分です。
実施すべき管理策:
- 変更にはコードレビューが必要です pipeline 設定ファイル(.github/workflows/, ジェンキンスファイルなど)
- 自己ホスト型ランナーは承認済みのリポジトリに限定してください。未審査のランナーへのアクセスは、認証情報の盗難に直結します。
- 機密情報を平文の環境変数として渡さないでください。機密情報管理ツールとの連携を使用してください。
- 監査委員会 pipeline 予期しないコマンド、異常なネットワーク呼び出し、または予期しない時間帯の実行に関するログ
ザイゲニ CI/CD セキュリティ 実施する guardrails あなたの中で直接 pipeline 安全でないビルドをブロックし、注入されたワークフローを検出し、 pipeline あらゆる段階における誠実さ。 デモを予約する→
15. ビルドの整合性を検証し、成果物に署名する
攻撃者がビルドスクリプトにコードを挿入したり、コンパイル後に成果物を改変したり、CIランナーを侵害したりできる場合、ソースコードがどれほどクリーンであっても、攻撃者はあなたのソフトウェアサプライチェーンを完全に支配してしまうことになります。
ビルド整合性制御を適用する:
- すべての依存関係バージョンとベースイメージをタグではなく正確なダイジェストにピン留めします。
- デプロイ前にビルド成果物に署名し、署名を検証する
- 予期しない変更を監視します CI/CD ワークフローファイル、注入されたワークフローは、Shai-Huludのような攻撃における重要な指標でした。
- SLSA認証を実装して、何が、どのソースから、誰によって構築されたかを暗号的に証明する pipeline
脅威検知とインシデント対応
16. ロギングを一元化し、スタック全体にわたる可視性を構築する
見えないものは検出できません。ほとんどのクラウドセキュリティ監視は、ランタイム、CloudTrail、VPCフローログ、GuardDutyに焦点を当てています。これらは必要ではありますが、十分ではありません。
Shai-HuludやSolarWindsのような攻撃が成功した理由の一つは、侵害が構築段階で発生したことにある。 pipeline運用監視が本格的に導入されるずっと前から、完全な可視性を確保するには、ソースコードの変更、ビルドおよび成果物レイヤー、クラウドランタイム、APIアクティビティなど、あらゆる側面を網羅する必要があります。
17. 発見事項の優先順位付けは、深刻度だけでなく、活用可能性に基づいて行う。
週に500件もの検出結果を出すスキャナーは、重要なものも含め、検出結果を無視するようにチームを訓練してしまう。優先順位付けこそが、実際に機能するセキュリティプログラムと、机上の空論に終わるプログラムを分ける決定的な要素なのだ。
効果的な優先順位付けには、到達可能性(脆弱なコードが実際に実行されるか)、露出度(サービスがインターネットに接続されているか)、EPSSスコア(実際に悪用される可能性)、およびビジネスコンテキスト(本番環境か開発環境か)が組み合わされます。
Xygeni ASPM すべての調査結果が SAST, SCA, IaC秘密、そして pipeline security リスクを統合的に把握し、状況に応じた優先順位付けを行うことで、チームが最初に何を修正すべきかを正確に把握できるようにします。 デモを予約する→
18.行動基準値を設定し、逸脱があった場合は警告を発する
既知の悪意のあるシグネチャは、既知の脅威を検出します。行動異常検知は、未知の脅威、ゼロデイ攻撃、新しい攻撃パターン、内部脅威を検出します。
あなたのための CI/CD 具体的には、環境において、標準的なビルド時間、通常のパッケージインストールパターン、ビルド中の想定されるネットワーク宛先などのベースラインを確立し、 standard 機密情報へのアクセスパターン。これらの基準からの逸脱は、最も早期の警告信号であり、ほとんどのチームが全く把握できていない層です。
19. クラウド固有のインシデントシナリオに対するランブックを定義する
一般的なインシデント対応計画では、クラウド特有のシナリオ(例えば、既に40のサービスにインストールされている侵害されたパッケージ、悪意のあるプリインストールスクリプトによって認証情報が盗まれたCIランナー、過去72時間以内に改ざんされた可能性のあるビルド成果物など)は考慮されていません。
依存関係の侵害、 pipeline 認証情報の盗難、設定ミスによるデータ漏洩、悪意のあるCIワークフローの注入など。各ランブックでは、対応の責任者、即座に取り消されるもの、および被害範囲を特定するために必要なフォレンジックを明確に定義する必要があります。
20. テーブルトップエクササイズを実行するcis少なくとも年2回
テストされていないランブックは仮説に過ぎない。机上演習cis攻撃者が気づく前に、対応計画の欠陥を明らかにします。目標は手順書を完璧に実行することではなく、何が欠けているかを発見することです。
最低でも2回の運動をこなすcis年間 100 回のテストを実施し、サプライチェーンの侵害、設定ミスによるデータ漏洩、侵害された CI ランナーなど、さまざまなシナリオをシミュレーションします。実際に対応するチーム、セキュリティ、DevOps、およびオンコール開発者を含めます。
クラウドセキュリティのヒントチェックリスト:クイックリファレンス
| 層 | キーコントロール |
|---|---|
| アイデンティティ | あらゆる場所での多要素認証、最小権限、有効期限の短い認証情報、ジャストインタイムアクセス |
| Rescale データ | 保存時および転送時の暗号化、秘密情報のスキャンと自動失効、データ分類 |
| インフラ | IaC スキャン中 commitポリシー・アズ・コード、 CIS ベースラインの強制、ネットワークのセグメンテーション |
| サプライチェーン | SCA 到達可能性とマルウェア検出機能を備え、 CI/CD 強化、構造の完全性、SLSA |
| 検出 | 集中ログ記録、EPSSベースの優先順位付け、行動異常検出 |
| 世界の動き | クラウド固有の実行手順書、卓上演習cis爆発半径評価の記録 |
Xygeniがクラウドセキュリティのヒントをフルスタック全体に適用するのに役立つ方法
クラウドセキュリティのヒントは、チームがソフトウェア開発ライフサイクル全体にわたって一貫して適用できる場合にのみ効果を発揮します。ほとんどのツールは、ランタイム、コード、依存関係、シークレット、または CI/CDしかし、実際の攻撃は複数の階層をまたいで行われる。
Xygeniは、最初のgit pushから本番環境へのデプロイまで、統合された検出、優先順位付け、および修復機能によってこれらのレイヤーを接続します。
| 層 | Xygeniの機能 | 何を防ぐのか |
|---|---|---|
| ソースコード | SAST + AIによる修復 | インジェクション、認証失敗、安全でない設計 |
| 依存関係 | SCA + マルウェア検出 + EPSS | サプライチェーンの混乱、脆弱なパッケージ |
| シークレット | シークレットセキュリティ + 自動失効 | 認証情報の漏洩、長期トークンのリスク |
| IaC &設定 | IaC Security | 生産段階に入る前の設定ミス |
| CI/CD Pipeline | CI/CD セキュリティ+異常検知 | Pipeline 注入、ランナー妥協 |
| 成果物を構築する | Build Security + SLSA provenance | 改ざんされたアーティファクト、署名のないリリース |
| リスク姿勢 | ASPM | 統合ビュー、クロスレイヤー優先順位付け |
その結果、セキュリティチームはノイズではなくシグナルを受け取ることができ、開発者は普段使っているツールではなく、作業現場でフィードバックを受け取ることができる。そして、セキュリティは開発プロセスを遅らせる障壁ではなく、開発プロセスの一部となる。
最終的な考え
クラウドセキュリティのヒントは簡単に挙げられますが、それを徹底するのは難しいです。真のクラウドリスクを軽減するチームは、手動レビュー、分散したツール、または深刻度のみに基づく優先順位付けに頼るのではなく、セキュリティ制御を自動化します。 pipeline脆弱性を悪用可能性に基づいて優先順位付けし、ソフトウェアサプライチェーン全体をクラウド攻撃対象領域の一部として扱う。
それは、ランタイムインフラストラクチャを保護するだけでなく、ソースコード、依存関係、秘密情報、 IaC, CI/CD ワークフロー、ビルド成果物、およびアプリケーションのリスク状況を同時に管理する。
現在お使いのツールではこれらのレイヤー間にギャップが生じる場合、Xygeniはコードからクラウドまでの全パスにわたる統合的な検出、優先順位付け、および修復機能によって、そのギャップを埋めるのに役立ちます。
👉 7日無料トライアルを開始 クレジットカード不要、スキャン結果は数分で表示
👉 デモを予約する Xygeni が特定のクラウドにどのようにマッピングされるかを確認し、 pipeline
著者について
共同創業者兼CTO
ファティマ Said AppSec、DevSecOps、および software supply chain security彼女は複雑なセキュリティシグナルを明確で実行可能なガイダンスに変換し、チームがより迅速に優先順位付けを行い、ノイズを減らし、より安全なコードを出荷できるよう支援します。




