次の方法で共有

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

この記事は、開発者が開発環境をセキュリティで保護し、 ゼロ トラスト原則 (明示的に確認し、最小限の特権アクセスを使用し、侵害を想定する) を実装できるようにするために役立ちます。 Enterprise DevOps Environment のセキュリティ保護 に関する電子ブックの内容を取り上げます。また、ブランチセキュリティと信頼ツール、拡張機能、統合に関するベスト プラクティスが強調されています。

開発者のスピードは、望む方法や場所で作業し、ビジネス成果を最大化する能力に依存します。 ルートまたは管理者アクセス権を持つ強力でカスタマイズ可能なマシンが必要です。 ただし、開発者の要求は、コンプライアンス規制や、プライベート従業員環境のアクセスとストレージを監査および制御する必要性に反して実行される可能性があります。

組織のネットワークに接続するアンマネージド マシンは、セキュリティ チーム、調達部門、およびガバナンス ボードに対する課題となっています。 開発者に標準化されたセキュリティ強化済みの従業員環境を提供する最良のシナリオでも、双方に不満が生じることがあります。 従業員がどこからでも接続する場合、脆弱な Wi-Fi ネットワークはサイバー攻撃の門戸です。 ハードウェアの盗難と損失は大きな懸念事項です。

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

次の図では、開発者環境が DevOps ツール環境に接続して Git ブランチに影響を与える方法に注目してください。 オープンソース パッケージとアプリケーション拡張機能への接続を通じて環境の表面を広げます。 拡張機能は、依存関係と拡張アプリケーションの脆弱性に脆弱性を示します。

図は、開発者環境とセキュリティの脅威を示しています。

DevOps チーム メンバーに、悪意のある攻撃を防ぎながら柔軟性と制御を提供することは、セキュリティ オフィスにとって基本的な課題です。 DevOps は、クラウド環境を使用して開発環境を制御し ( Azure VM の信頼された起動 と GitHub Enterprise Cloud Docs を参照)、コンテナーを使用して開発環境をセキュリティで保護できます ( GitHub Codespaces のドキュメントを参照)。

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

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

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

開発者は、多くの場合、自分の環境でマルウェア、フィッシング、侵害をキャッチすることができると考えています。 大規模な開発者環境の脅威の表面は、開発者が全能的なシステム知識を維持することを非現実的にします。 攻撃によってすべてのシステムへの管理者アクセス権を持つ開発環境が侵害された後に侵害が検出されると、組織は貴重な修復時間を失います。

不適切なアクターがソフトウェア開発者ロールをターゲットにする可能性のあるアクセス機会を修復するには、次のアプリのゼロ トラスト最小特権 セキュリティのベスト プラクティスを検討してください。

  • DevOps の最小特権と Just-In-Time アクセスを実装します。 チーム メンバーが必要な最短の時間だけ環境へのアクセスを最小限に抑えるようにします。 メイン デバイス、DevOps ツール、リリース パイプライン、コード リポジトリ、環境、シークレット ストア、データベースに対する管理者アクセス権をカバーするポリシーを配置します。 DevOps チームの場合、基本要件は 組織 ID ストアへの接続です。 Id フェデレーションを使用して SaaS 環境と統合し、Microsoft 以外のプラットフォームでの ID の重複を回避し、露出リスクを軽減します。
  • ソース コードへのアクセスには個人用アクセス トークンを使用しないでください。 DevOps チームのセキュリティで保護されたプラクティスには、SaaS ベースの DevOps ツール、コード リポジトリ (SSH、HTTPS、または個人用アクセス トークン経由) へのアクセスが含まれます。 SaaS ベースの環境アクセスの場合、アクセス原則によって、システム コード リポジトリをダウンロード (複製) できるユーザーと、どのデバイス (ローカル、クラウド、コンテナー) からダウンロード (複製) できるかが明確に指示されます。 たとえば、OneDrive では 、アンマネージド デバイス アクセスをブロックまたは制限できます。
  • GitHub Enterprise Managed User (EMU) ユーザー アカウントを標準化し、企業 ID と同期します。 Enterprise Managed Users では、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 Enterprise Cloud では、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 Marketplace 拡張機能のみを組み込みます。 VS Code を使用してアプリケーション拡張機能をインストールする場合は、コマンド ライン、コード --list-extensions --show-versionsで実行している拡張機能を定期的に確認します。 開発環境で実行している拡張可能なコンポーネントについて十分に理解してください。

次のステップ

  • Last updated on