次の方法で共有

ゼロ トラストの開発環境をセキュリティで保護する

  • [アーティクル]

この記事は、開発者がゼロ トラストの原則 (明示的に検証する、最小特権アクセスを使用する、侵害を想定する) を実装できるように、開発環境をセキュリティで保護するのを支援します。 本記事は、eBookエンタープライズ DevOps 環境のセキュリティ保護からのコンテンツを引用しており、特にブランチセキュリティと信頼ツール、拡張機能、統合のベスト プラクティスに焦点をあてています。

開発者のスピードは、ビジネス成果を最大化する方法と場所をどの程度自由にコントロールできるかに依存します。 ルート権限または管理者権限で利用できる強力でカスタマイズ可能なマシンが必要です。 ただし、開発者のニーズは、コンプライアンス規制や、従業員のプライベート環境へのアクセスとストレージを監査および制御したい組織のニーズと相反することがあります。

組織のネットワークに接続するアンマネージド マシンの存在は、セキュリティ チーム、調達、ガバナンス委員会にとっては脅威になります。 どんなに優れたシナリオで開発者にデフォルトでセキュリティ強化された従業員環境を提供しても、両側にあつれきが生じます。 従業員がどこからでもネットワークに接続する可能性がある場合、脆弱な Wi-Fi ネットワークはサイバー攻撃の格好の標的となります。 ハードウェアの盗難と損失も大きな懸念事項です。

脆弱性は開発環境の統合にまで及びます。 豊富な機能拡張を備えた開発ツールでは、マーケットプレースに管理されていない統合が存在する可能性があります。 有害な拡張機能は開発者ツールを危険にさらし、全社的なセキュリティ侵害を引き起こす可能性があります。

次の図では、開発者環境が DevOps ツール環境に接続して Git ブランチに影響を与えていることに注目してください。 これは、オープンソース パッケージとアプリケーション拡張機能への接続を通じて、環境表面を拡大します。 拡張機能は、依存関係と拡張アプリケーションにおける脆弱性をねらった攻撃ベクトルとなり得ます。

図は、前の電子ブックで説明した開発者環境とセキュリティの脅威と、ここにリンクされている関連記事のまとめを示します。

有害な攻撃を防ぎながらDevOps チーム メンバーに柔軟性とコントロールを提供することは、セキュリティ管理部門にとって危急のかつ困難な課題です。 DevOps は、クラウド環境を使用して開発者環境を制御し (Azure VM のための信頼できる立上げと GitHub エンタープライズ クラウド ドキュメント を参照)、コンテナーを利用して開発者環境のセキュリティを確保できます (GitHub の Codespaces ドキュメントを参照)。

さらに、開発者は、開発者環境のセキュリティを確保するため、次のゼロ トラスト対策を実装することができます。

  • 最小特権の原則を組み込むこと。
  • ブランチ セキュリティを使用して、どのユーザーがコードを変更および承認できるかを制限すること。
  • 信頼できるツール、拡張機能、統合のみを採用すること。

最小特権のベスト プラクティス

開発者は、多くの場合、自分たちの環境内でマルウェア、フィッシング、セキュリティ侵害を検出することができると考えています。 しかし、開発者環境の脅威サーフェスが大きいため、開発者が自分たちのシステムに関する万能かつ完全な知識を維持し続けるのは非現実的と言ってよいでしょう。 攻撃によってすべてのシステムへの管理者アクセス権を持つ開発環境が侵害された後に侵害が検出されると、組織では貴重な修復時間が失われます。

ハッカーがソフトウェア開発者ロールを標的にする潜在的なアクセスチャンスを防ぐには、以下のゼロ トラスト最小特権原則に基づくアプリケーション セキュリティのベスト プラクティスを参考にしてください。

  • DevOps の最小特権と Just-In-Time アクセスの原則を実施すること。 チーム メンバーが環境にアクセスする時間とアクセス範囲を最小限に抑えるようにします。 メイン デバイス、DevOps ツール、リリース パイプライン、コード リポジトリ、環境、シークレット ストア、データベースに対する管理者アクセス権を管理するポリシーを設定運用します。 DevOps チームの場合、基本要件は 組織 ID ストアへの接続です。 サード パーティのプラットフォームでの ID の重複を回避し露出リスクを軽減するために、SaaS 環境との統合には ID フェデレーションを使用します。
  • ソース コードへのアクセスには個人用アクセス トークンを使用しないでください。 DevOps チーム向けセキュリティプラクティスには、SaaS ベースの DevOps ツールとコード リポジトリ (SSH、HTTPS、または個人用アクセス トークン経由) へのアクセスが含まれます。 SaaS ベースの環境アクセスの場合、アクセス原則によって、どのユーザーがシステム コード リポジトリをダウンロード (複製) できるか、またそれをどのデバイス (ローカル、クラウド、コンテナー) から実行できるかを明確に規定すること。 たとえば、OneDrive では、アンマネージド デバイスからのアクセスをブロックまたは制限できます。
  • GitHub エンタープライズ マネージド ユーザー (EMU) のユーザー アカウントを標準化し、企業 ID と同期させること。 エンタープライズ マネージド ユーザーでは、お使いのID プロバイダー (IdP) を使用してエンタープライズ メンバーのユーザー アカウントをコントロールできます。 組織の ID ストアで、GitHub のユーザー名、電子メール、表示名を明示的に定義すること。 ユーザーは共同作業者を簡単に識別できます。
  • 開発者が SaaS 環境に接続する 3 つの方法 (ID を使用した HTTPS、個人用アクセス トークン、SSH キーによる接続) については、組織の ID ストアとの接続を行います。 GitHub (GitHub EMU アカウントを除く) では、ID は常にパブリック ID となります。 シングル サインオン (SSO) を使用したアクセス制御を行うには、組織の ID ストアとの接続が必要です。
  • SSH 証明機関 (CA) を使用して、Git でリソースに安全にアクセスするための署名付き SSH 証明書をメンバーに提供しましょう。 SSH 証明書とは、1つの SSH キーでもうひとつの SSH キーに署名する仕組みです。 GitHub エンタープライズ クラウドによるSSH 証明書のサポートにより、組織はメンバーがリポジトリにアクセスする方法をよりきめ細かく制御できます。 管理者は、SSH CA 公開キーをアップロードし、メンバーが Git 認証に使用できる証明書を発行することができます。 証明書は、組織に属するリポジトリにのみアクセスできます。 管理者は、メンバーがリポジトリにアクセスするときに証明書の使用を必要とするよう設定できます。
  • Git 認証情報マネージャーを使用して、コードへのアクセス保護を強化します。 Visual Studio (VS) などのツールには、ID サポートが組み込まれています。 VS Code は Git Credential Manager に従います。

セキュリティのベスト プラクティス

もしハッカーがコード リポジトリへのアクセスを確保すると、チームに気付かずにシステム セキュリティを調べてコードを改変することができるようになります。 コード リポジトリへの未承認のアクセスを防ぐには、ブランチ戦略を実装してコード変更に対するコントロールを確立します (次の図に示す例を参照)。

図は、メイン リポジトリを保護する分岐戦略の例を示しています。

リポジトリへの潜在的なアクセスチャンスを防ぐには、次のブランチ セキュリティのベスト プラクティスを検討してください。

  • コード レビューによりブランチを保護し、DevOps チームがコードの変更や監査行為をコントロールできるようにします。 前の図のブランチ戦略は、コード変更に対処するための明確な命令系統とブループリントを示す管理された変更フローを明示しています。 ブランチ戦略にはさまざまなアプローチがありますが、 1 つの共通点は、保護されたブランチを本番環境への新しいリリース源として機能させることです。
  • Git リポジトリの管理者に承認許可をコントロールしてもらうこと。 ブランチ戦略の制御メカニズムは、承認ワークフロー内にあります。 保護されたブランチにおいては、変更を受け入れる前に検証、レビュー、承認が必要となります。 1 つのオプションは、ワークフローを執行するブランチ保護規則を策定することです。 たとえば、保護されたブランチに統合されるすべてのプル要求に対して、承認レビューまたはステータスチェックをクリアしていることを要件とすることができます。 ブランチ ポリシーは、チームが開発における重要なブランチを保護するのに役立ちます。 ポリシーによって、チームのコード品質と変更管理基準を確実に運用します。

信頼ツール、拡張機能、統合のためのベスト プラクティス

統合開発者環境 (IDE) での拡張性は非常に生産性が高く、開発業務には欠かせない要素です。 最適な作業環境を設計するには、特定の IDE のマーケットプレース内の拡張機能を確実に適用およびキュレーションできるようにすること。

セキュリティ保護された IDE を確保するには、次のツール、拡張機能、統合のベスト プラクティスを検討してください。

  • マーケットプレースと発行元両方が信頼できるツールのみを統合してください。 たとえば、VS Code マーケットプレース には、業務を効率化するための何千もの拡張機能があります。 しかし、チームが新しいツールや拡張機能を導入する場合、最も重要な側面は、発行元の信頼性を確認することです。
  • 拡張機能の使用をコントロールして開発者環境のアタックサーフェスを抑制するためのセキュアで安全なベストプラクティスを設定すること。 ほとんどの IDE 拡張機能は、所定の特権に対する承認がないと機能できないように設定されており、これはコードを分析するシステムに対する読み取りアクセス許可を持つファイルとして提供されることが多いです。 拡張機能が機能するには、クラウド環境への接続が必要です (メトリック ツールでよく使用されます)。 IDE 上で追加機能を承認すると、組織はより多くの脅威に対して脆弱になります。
  • 開発者マシン上で、使用される拡張機能の数と成熟度を管理追跡し、潜在的なアタックサーフェスを常に把握しておきましょう。 検証済みパブリッシャーからの VS Codeマーケットプレイス拡張機能のみを組み込むようにします。 VS Code を使用してアプリケーション拡張機能をインストールする場合は、コマンド ライン code --list-extensions --show-versions を使用して実行している拡張機能を定期的に確認してください。 開発者環境内でどんな拡張可能なコンポーネントを実行しているかを十分に把握しておくこと。

次のステップ