ゼロ トラストのための開発者環境のセキュリティ保護

この記事は、開発者が開発者環境をセキュリティ保護し、ゼロ トラスト原則 (明示的な検証、最小限の特権アクセス、侵害の想定) を実装するのに役立ちます。 本記事は、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 認証情報マネージャーに 遅延します。

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

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

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

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

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

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

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

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

次のステップ

• 開発者ワークフローにゼロ トラストセキュリティを埋め込むは、開発者が迅速かつ安全にイノベーションを推進するためのヒントを提供します。
• DevOps プラットフォーム環境のセキュリティ保護は、DevOps プラットフォーム環境にゼロ トラスト原則を実装する方法と、シークレットと証明書の管理のためのベスト プラクティスを説明します。
• ゼロ トラストのための DevOps 環境のセキュリティ保護は、ゼロ トラスト原則に基づいてDevOps 環境のセキュリティを確保することにより、ハッカーが開発者ボックスに侵入したり、リリース パイプラインを有害なスクリプトに感染させたり、テスト環境を介して本番環境データにアクセスすることを防ぐためのベスト プラクティスを説明します。
• Microsoft Entra ID を一元化された ID 管理システムとして運用することで、覚書 22-09 (米国行政命令 14028「国家のサイバーセキュリティの向上」に準拠) に記載されるゼロ トラスト原則を実装します。
• クラウド エクスペリエンスに対する最も高速で最も安全なコードを開発者に提供するツールにより、Azure DevOps を使用してコードを高速化し、セキュリティで保護します。
• GitHub の OIDC をフェデレーション ID として信頼するように Azure を構成します。 OpenID Connect (OIDC) を使用すると、GitHub Action ワークフローから Azure 内のリソースにアクセスできます。このとき、Azure 認証情報を有効期間が長い GitHub シークレットとして格納する必要はありません。