次の方法で共有

DevOps のセキュリティ (DevSecOps)

  • [アーティクル]

セキュリティは、DevOps の重要な部分です。 しかし、チームはシステムが安全かどうかをどのようにして知るのでしょうか? 完全に安全なサービスを提供することは本当に可能でしょうか?

残念ながら、答えはノーです。 DevSecOps は継続的かつ継続的な取り組みであり、開発と IT 運用の両方の全員の注意を必要とします。 仕事が実際に完了することはありませんが、チームが侵害を防止し、対処するために採用するプラクティスは、可能な限り安全で回復力のあるシステムを生み出すのに役立ちます。

「基本的に、誰かが入りたいなら、彼らは入るのです...それを受け入れてください。 私たちがクライアントに言いたいのは、第一に、自分がそう思っているかどうかにかかわらず、あなたは戦いの中にいるということです。 2 番目に、ほぼ確実に侵入されます。」 -- マイケル・ヘイデン、元 NSA および CIA 長官

セキュリティに関する会話

正式な DevSecOps 戦略を持っていないチームは、できるだけ早く計画を開始することをお勧めします。 最初は、存在する脅威を十分に理解していないチームメンバーからの抵抗があるかもしれません。 他には、チームが問題に直面する準備ができていて、特別な投資が出荷機能からの無駄な気晴らしになると感じてない人もいるかもしれません。 ただし、リスクの性質、チームがリスクを軽減する方法、チームが現在持っていないリソースが必要かどうかについて合意を形成するために会話を開始する必要があります。

懐疑的な人が次のようないくつかの一般的な議論をもたらすことを期待してください。

  • 脅威はどのくらい現実的ですか? 多くの場合、チームは保護に関して課金されるサービスとデータの潜在的な価値を評価しません。
  • 私たちのチームは問題ないですか? セキュリティに関する議論は、安全なシステムを構築するチームの能力に疑問があるとみなされる可能性があります。
  • 私はそれが可能だとは思いません。 これは、後輩エンジニアから持ち込まれる一般的な議論です。 経験のある人の方が、通常は、知識があります。
  • 侵害されたことはありません。 しかし、どうやってそのことを知りましたか。 "どうすれば" わかるのでしょうか。
  • 価値に関する無限の議論。 DevSecOps は、コア機能の作業から気を散らすものとして認識される可能性のある深刻な取り組みです。 セキュリティへの投資は他のニーズとバランスを取る必要がありますが、無視することはできません。

考え方の転換

DevSecOps 文化には、考え方の重要な変化が必要です。 侵害を防止するだけでなく、侵害を想定する必要もあります。

セキュリティ戦略の構成要素

より安全なシステムを追求するために適用できる技術は数多くあります。

侵害を防止する 侵害を想定する
脅威モデル 戦争ゲーム演習
コード レビュー 中央セキュリティ モニター
セキュリティ テスト ライブ サイト侵入テスト
セキュリティ開発ライフサイクル (SDL)

すべてのチームは、違反を防ぐために少なくともいくつかのプラクティスをすでに導入している必要があります。 安全なコードの記述がデフォルトになりつつあり、スタティック分析やその他のセキュリティ テスト機能を支援する無料および有料ツールがたくさんあります。

しかし、多くのチームには、システム侵害が避けられないことを前提とした戦略が欠けています。 自分が侵害されたと仮定することは、特に経営陣と難しい会話をしているときに認めるのが難しい場合がありますが、その仮定は、自分の時間でセキュリティに関する質問に答えるのに役立ちます。 実際のセキュリティ上の緊急事態においては、すべてを把握したくないでしょう。

検討すべき一般的な質問は次のとおりです。

  • どうやって攻撃を検知するのでしょうか?
  • 攻撃や侵入があった場合、どのように対応するか?
  • データの漏洩や改ざんなどの攻撃からどうやって復旧するのでしょうか？

DevSecOps の主要な実践方法

事実上どのチームにも適用できる一般的な DevSecOps プラクティスがいくつかあります。

まず、平均検出時間と平均回復時間の改善に重点を置きます。 これらのメトリクスは、それぞれ侵害の検出にかかる時間と回復にかかる時間を示します。 これらは、セキュリティ対応計画の継続的なライブサイト テストを通じて追跡できます。 潜在的なポリシーを評価する際には、これらの指標を改善することが重要な考慮事項となります。

多層防御を実践してください。 侵害が発生すると、攻撃者は内部ネットワークとその内部のあらゆるものにアクセスできるようになります。 そこまで進行する前に攻撃者を阻止することが理想的ですが、侵害を想定するポリシーにより、チームはすでに侵入した攻撃者による危険を最小限に抑えようとします。

最後に、実践と環境の侵害後の評価を定期的に実行します。 侵害が解決された後、チームはポリシーのパフォーマンスとポリシーの遵守状況を評価する必要があります。 ポリシーは、チームが実際にポリシーに従っているときに最も効果的です。 実際の違反か実際に行われた違反かを問わず、すべての違反は改善の機会と見なされるべきです。

脅威を軽減するための戦略

脅威は多すぎてすべてを列挙することはできません。 一部のセキュリティ ホールは、オペレーティング システムやライブラリなどの依存関係の問題が原因であるため、それらを最新の状態に保つことが重要です。 その他は、発見と修正に慎重な分析を必要とするシステム コードのバグに起因します。 シークレットの管理が貧弱な場合、ソーシャル エンジニアリングと同様に、さまざまな侵害を引き起こします。 さまざまな種類のセキュリティ ホールと、それらがシステムにとって何を意味するかについて考えることをお勧めします。

攻撃ベクトル

攻撃者が開発者の資格情報にアクセスしたシナリオを考えてみましょう。 彼らに何ができるでしょうか？

権限 攻撃
メールを送信できるか? 仕事仲間に対するフィッシング
他のマシンにアクセスできるか? ログオン、Mimikatz、繰り返し
ソースを変更できますか コードの挿入
ビルドまたはリリースのプロセスを変更できるか? コードを挿入し、スクリプトを実行する
テスト環境にアクセスできるか? 運用環境がテスト環境に依存している場合は、それを悪用する
運用環境にアクセスできるか? 非常に多くのオプション...

あなたのチームはこれらのベクトルからどのように防御できるでしょうか?

  • 保護されたコンテナーにシークレットを保存する
  • ローカル管理者アカウントを削除する
  • SAMR を制限する
  • Credential Guard
  • デュアルホーム サーバーを削除する
  • 別個のサブスクリプション
  • 多要素認証
  • 特権アクセス ワークステーション
  • ATP による検出 & Microsoft Defender for Cloud

シークレットの管理

すべてのシークレットは、保護されたボールトに保存する必要があります。 シークレットには次のものが含まれます：

  • パスワード、キー、トークン
  • ストレージ アカウント キー
  • 証明書
  • 運用環境以外の共有環境でも使用される資格情報

シークレットの重複を排除するには、ボールトの階層を使用する必要があります。 また、シークレットにいつどのようにアクセスするかについても考慮してください。 環境構成を構築するとき、デプロイ時に使用されるものもあれば、実行時にアクセスされるものもあります。 デプロイ時シークレットは通常、新しい設定を取得するために新しいデプロイメントを必要としますが、実行時シークレットは必要に応じてアクセスされ、いつでも更新できます。

プラットフォームには、Azure Key Vault やGitHub Actions など、CI/CD パイプラインやクラウド環境でシークレットを管理するための安全なストレージ機能があります。

便利なツール

戦争ゲーム演習

Microsoft では、戦争ゲーム演習を行うのが一般的です。 これらは、2 つのチームがシステムのセキュリティとポリシーをテストするセキュリティ テスト イベントです。

赤 チームが攻撃者の役割を果たします。 彼らは、セキュリティのギャップを見つけるために現実世界の攻撃をモデル化しようとします。 何かを悪用できる場合は、侵害による潜在的な影響も実証されます。

青 チームは DevOps チームの役割を引き受けます。 彼らはレッドチームの攻撃を検知して対応する能力をテストします。 これは、状況認識を強化し、DevSecOps 戦略の準備状況と有効性を測定するのに役立ちます。

戦争ゲーム戦略を進化させる

戦争ゲームは、レッドチームが問題を見つけて悪用するよう動機付けるため、セキュリティを強化するのに効果的です。 おそらく、早い段階では予想よりもはるかに簡単になるでしょう。 自分たちのシステムへの積極的な攻撃を試みていないチームは、通常、攻撃者が利用できるセキュリティ ホールのサイズと量を認識していません。 青チームは何度も轢かれるため、最初は意気消沈するかもしれません。 幸いなことに、システムと慣行は時間の経過とともに進化し、青チームが一貫して勝つようになります。

戦争ゲームの準備をする

戦争ゲームを開始する前に、チームはセキュリティ パスを通じて見つかった問題に対処する必要があります。 これは、後で最初のエクスプロイトが見つかった後に全員が比較するためのベースライン エクスペリエンスを提供するため、攻撃を試みる前に実行するのに最適な演習です。 まず、手動のコード レビューと静的分析ツールを通じて脆弱性を特定します。

チームを整理する

赤チームと青チームは専門分野ごとに編成する必要があります。 目標は、可能な限り効果的に実行するために、各陣営に最も有能なチームを構築することです。

レッド チームには、コードに精通したセキュリティ志向のエンジニアと開発者が含まれている必要があります。 可能であれば、チームに侵入テストのスペシャリストを増員することも役立ちます。 社内に専門家がいない場合、多くの企業がメンタリングと合わせてこのサービスを提供しています。

青色のチームは、利用可能なシステムとログを深く理解している運用志向のエンジニアで構成する必要があります。 彼らは、不審な動作を検出して対処できる可能性が最も高くなります。

初期の戦争ゲームを実行する

序盤戦ではレッドチームが効果を発揮することが期待される。 保護が不十分なシークレット、SQL インジェクション、フィッシング キャンペーンの成功など、非常に単純な攻撃でも成功できるはずです。 ラウンド間には十分な時間をとって、ポリシーに対する修正とフィードバックを適用します。 これは組織によって異なりますが、前のラウンドですべての価値がマイニングされたと全員が確信するまでは、次のラウンドを開始しないでください。

現在進行中の戦争ゲーム

数回のラウンドの後、レッド チームは、クロスサイト スクリプティング (XSS)、逆シリアル化エクスプロイト、エンジニアリング システムの脆弱性など、より高度な技術に依存する必要があります。 より目立たないエクスプロイトを攻撃するには、Active Directory などの分野の外部のセキュリティ専門家を招くことが役立つ場合があります。 この時点までに、青チームは防御するための強化されたプラットフォームを備えているだけでなく、侵害後のフォレンジックのために包括的で一元化されたログを利用する必要があります。

「防御者はリストで思考する。 攻撃者はグラフで思考する。 これが真実である限り、攻撃者が勝つ」 -- ジョン・ランバート (MSTIC)

時間が経つにつれて、レッドチームが目標を達成するまでにさらに長い時間がかかるようになります。 その場合、影響を限定的にするには、複数の脆弱性を発見して連鎖させる必要があることがよくあります。 リアルタイム監視ツールを使用することで、青チームは試行をリアルタイムで捕捉し始めるはずです。

ガイドライン

戦争ゲームは自由にできるものであってはなりません。 目標は、より効果的なチームによって運営される、より効果的なシステムを生み出すことであることを認識することが重要です。

倫理規定

Microsoft が使用する行動規範のサンプルを次に示します。

  1. 赤チームも青チームもダメージはありません。 損害を引き起こす可能性が大きい場合は、文書化して対処する必要があります。
  2. レッドチームは、ターゲット資産を取得するために必要以上に妥協すべきではありません。
  3. 物理的攻撃には常識的なルールが適用されます。 レッドチームは、ソーシャル エンジニアリングなどの非技術的な攻撃で創造性を発揮することが奨励されていますが、偽のバッジを印刷したり、人々に嫌がらせをしたりするべきではありません。
  4. ソーシャル エンジニアリング攻撃が成功した場合は、侵害された人の名前を公開しないでください。 全員が引き続き協力する必要があるチームメンバーを疎外したり当惑させたりすることなく、教訓を共有できます。

関与規則

Microsoft が使用する関与規則のサンプルを次に示します。

  1. どのシステムの可用性にも影響を与えません。
  2. 外部の顧客データにはアクセスしないでください。
  3. どのサービスでも、インプレースのセキュリティ保護を大幅に弱めないでください。
  4. リソースに対して意図的に破壊的なアクションを実行しないでください。
  5. 取得した資格情報、脆弱性、その他の重要な情報を保護します。

成果物

セキュリティ リスクや学んだ教訓は、修復項目のバックログに文書化する必要があります。 チームは、セキュリティ リスクにどれだけ迅速に対処するかについてのサービス レベル アグリーメント (SLA) を定義する必要があります。 重大なリスクにはできるだけ早く対処する必要がありますが、軽微な問題には 2 スプリントの期限がある場合があります。

学んだ教訓と発見された脆弱性を含むレポートを組織全体に提出する必要があります。 誰にとっても学びの機会ですので、ぜひご活用ください。

マイクロソフトで学んだ教訓

マイクロソフトは定期的に戦争ゲームを実施しており、その過程で多くの教訓を学んできました。

  • 戦争ゲームは、DevSecOps 文化を変え、セキュリティを最優先に保つための効果的な方法です。
  • フィッシング攻撃は攻撃者にとって非常に効果的であるため、過小評価すべきではありません。 本番環境へのアクセスを制限し、2 要素認証を要求することで影響を抑えることができます。
  • エンジニアリングシステムを制御することは、すべてを制御することにつながります。 ビルド/リリース エージェント、キュー、プール、定義へのアクセスは必ず厳密に制御してください。
  • 攻撃者を困難にするために、多層防御を実践してください。 彼らが突破しなければならない境界はすべて彼らの速度を低下させ、彼らを捕まえる別の機会を与えます。
  • 信頼領域を越えないでください。 実稼働環境では、テストの内容を決して信頼してはなりません。

次のステップ

セキュリティ開発ライフサイクル とAzure 上の DevSecOps の詳細をご覧ください。