GitHub の DevSecOps

Azure Active Directory
Monitor
ポリシー
Azure Security Center

開発の最初のステップから、DevSecOps はセキュリティのベストプラクティスを順守しています。 DevSecOps では、シフトレフト戦略を使用して、セキュリティ フォーカスがリダイレクトされます。 最後の監査に目を向けるのではなく、最初の開発にシフトします。 堅牢なコードを作成するだけでなく、このフェイル ファスト アプローチを使用すると、修正が容易な早期に問題を解決するのに役立ちます。

多くのセキュリティ機能を備えている GitHub は、DevSecOps ワークフローのすべての部分をサポートするツールを提供しています。

  • 組み込みのセキュリティ拡張機能を備えたブラウザーベースの IDE。
  • セキュリティ アドバイザリを継続的に監視し、脆弱で古い依存関係を置き換えるエージェント。
  • ソースコードの脆弱性をスキャンする検索機能。
  • 開発、テスト、およびデプロイのすべての手順を自動化するアクションベースのワークフロー。
  • セキュリティの脅威をプライベートで議論して解決してから、情報を公開する方法を提供するスペース。

Azure の監視および評価機能と組み合わせることで、これらの機能はセキュアなクラウド ソリューションを構築するための優れたサービスを提供します。

考えられるユース ケース

GitHub DevSecOps インストールは、多くのセキュリティ シナリオに対応しています。 次のケースの可能性があります。

  • セキュリティ機能を提供する事前構成済みの環境を利用しようとする開発者。
  • すぐに使える最新の優先順位付けされたセキュリティ レポートに加えて、影響を受けるコードや推奨される修正についての詳細情報に依存する管理者。
  • コードに秘密が公開されている場合、システムに自動的に新しい侵害されていないセキュリティ デバイスを取得させる必要がある効率化された組織。
  • より新しいか、またはセキュリティが強化されたバージョンの外部パッケージが利用可能になったときの自動アップグレードの利点が得られる可能性がある開発チーム。

アーキテクチャ

GitHub DevSecOps 環境内のさまざまな GitHub および Azure コンポーネントで実行されるセキュリティ チェックを強調表示しているアーキテクチャ図。

GitHub DevSecOps 環境内で実行されるセキュリティ チェックを強調表示しているアーキテクチャ ダイアグラム。 Azure AD で開発者が認証されると、Codespaces によってセキュリティ スキャンが実行されます。 次に GitHub Actions によって、セキュリティがテストされ、機密データが暗号化されます。 運用環境では、Azure Policy、Azure Security Center、および Azure Monitor によって、デプロイされたソフトウェアのリスクが評価されます。

このアーキテクチャの .svg をダウンロードします。

  1. 開発者が GitHub リソースにアクセスすると、GitHub によってそれらが SAML 認証のために Azure Active Directory (Azure AD) にリダイレクトされます。 シングルサインオン (SSO) の手順で、Microsoft Authenticator アプリでは、FIDO2 の強力な認証が使用されます。 パスワードなし FIDO2 セキュリティ キーは、最新の Fast Identity Online (FIDO) Alliance 仕様に従います。
  2. 開発者は、Codespaces でタスクの操作を開始します。 コンテナーに編成されたこれらの構築済みの開発環境では、必要なセキュリティ スキャン拡張機能を備える正しく構成された IDE が提供されます。
  3. 開発者が新しいコードをコミットすると、GitHub Actions によって、コードが自動的にスキャンされ、脆弱性とコーディング エラーが速やかに検出されます。
  4. プル要求 (PR) では、GitHub Actions によって、コードのビルドと自動テストがトリガーされます。 GitHub では、保存時に秘密と資格情報が暗号化され、これらのエントリがログに難読化されます。
  5. GitHub Actions では、サービス エンドポイントなどの他のクラウド リソースに変更が加えられると同時に、ビルド アーティファクトが Azure App Service にデプロイされます。
  6. Azure Policy によって、デプロイ中の Azure リソースが評価されます。 さらに定義済みのポリシーによって、リリースの拒否、クラウド リソースの変更、またはアクティビティ ログでの警告イベントの作成が行われる可能性があります。
  7. Azure Security Center では、デプロイされたプロジェクトで実行されているアプリケーションを対象とする攻撃が特定されます。
  8. Azure Monitor によって、アプリの動作が継続的に追跡され、評価されます。 脅威が具体化された場合は、このサービスによってアラートが送信され、コードを以前のコミットにロール バックするプロセスが開始されます。

コンポーネント

  • Azure AD は、Azure および、Microsoft 365 や GitHub などのその他のクラウド アプリへのアクセスを制御するマルチテナント クラウドベースの ID サービスです。
  • GitHub には、オープンソース プロジェクトと内部ソース プロジェクトのコラボレーションに使用できるコードホスティング プラットフォームが用意されています。
  • Codespaces はオンライン開発環境です。 GitHub によってホストされ、Visual Studio Code によって強化されているこのツールは、クラウドでの完全な開発ソリューションになります。
  • GitHub セキュリティは、さまざまな方法で脅威を解消するように機能します。 エージェントとサービスによって、リポジトリと依存パッケージの脆弱性が特定されます。 さらに、それらによって、依存関係が最新のセキュアなバージョンにアップグレードされます。
  • GitHub Actions は、リポジトリに継続的インテグレーション (CI) 機能と継続的配置 (CD) 機能を直接提供するカスタム ワークフローです。 ランナー と呼ばれるコンピューターで、これらの CI/CD ジョブがホストされます。
  • App Service には、Web アプリの構築、デプロイ、およびスケーリングを行うためのフレームワークが用意されています。 このプラットフォームでは、組み込みのインフラストラクチャ メンテナンス、セキュリティ パッチ、およびスケーリングが提供されます。
  • Azure Policy は、チームがクラウド リソースにルールを適用できるポリシー定義によって、IT の問題を管理し防止するのに役立ちます。 たとえば、プロジェクトで、認識されていない SKU がある仮想マシンをデプロイしようとしている場合は、Azure Policy によって、問題が警告され、デプロイが中止されます。
  • Azure Security Center は、ハイブリッド クラウド ワークロード全体で統合されたセキュリティ管理と高度な脅威保護を実現します。
  • Azure Monitor によって、パフォーマンス メトリックやアクティビティ ログなどのアプリ テレメトリが収集され、分析されます。 このサービスで、不規則な状態が特定されると、アプリと担当者に通知されます。

セキュリティ

GitHub セキュリティには、セキュリティ上のリスクに対処するための多数の機能が用意されています。

  • コード スキャンでは、既知の脆弱性とコーディング エラーについて、コードが検査されます。 たとえば、開発者がコードにデータベース接続文字列を公開したままにすると、この機能によって秘密が検出されます。 データベースを使用してその有効性が確認されると、GitHub によって侵害されていない文字列を取得するプロセスが開始されます。 これらのチェックでは、CodeQL が使われます。これは、コードをデータとして扱うことによって、従来のアナライザーを改善するコード分析プラットフォームです。 スキャンは、スケジュールされた時刻に、またはコミットやプッシュなどの特定のイベントが発生した後に、自動的に実行されます。

  • GitHub Dependabot により、古いかまたは脆弱なパッケージとアプリケーションがチェックされます。 この自動エージェントによりソフトウェアを更新し、古いかまたは安全でない依存関係を新しいセキュアなバージョンに置き換えます。 たとえば、プロジェクトでオープンソース ライブラリを使用している場合、Dependabot によってそのライブラリが調査されます。 ライブラリで、データベースに格納する機密クリアテキストが暗号化されていないとします。 この場合、Dependabot によって、データを暗号化するバージョンにライブラリをアップグレードする PR が作成されます。

  • 脆弱性管理では、コードと、コードで使用しているソフトウェア パッケージの既知の脆弱性が特定され、更新されます。 次のイベントが発生するたびに、検査が実行されます。

    • リポジトリの依存関係が変更される (たとえば、プロジェクトが .NET から .NET Core に切り替わった場合)。

    • WhiteSource から通知が表示される。 このサードパーティ サービスでは、オープンソース リポジトリを継続的にスキャンして脆弱性が追跡されます。

    • GitHub Advisory Database に新しい脆弱性が入力される。 このデータベースのエントリは、次のソースに由来します。

GitHub で脆弱性が特定されると、次のダイアグラムに示す手順が実行されます。

アラート、アップグレード、デプロイなど、脆弱性の特定によってトリガーされるイベントのチェーンを示すアーキテクチャ ダイアグラム。

GitHub DevSecOps 実装のイベントのチェーンを示すアーキテクチャ ダイアグラム。 最初に、GitHub で脆弱性が特定され、電子メール アラートが送信されます。 次に Dependabot によってブランチが作成され、脆弱性ソースが更新されて、PR が作成されます。 ブランチがマージされます。 最後の手順では、GitHub Actions によって新しいアプリがデプロイされます。

このダイアグラムの .svg をダウンロードします。

  1. GitHub によって、組織の所有者とリポジトリ管理者に電子メール アラートが送信されます。
  2. DevOps ボット エージェントの GitHub Dependabot によって次の 3 つのタスクが自動的に実行されます。
    1. リポジトリに新しいブランチを作成します。
    2. 脆弱性を解消するために必要な最小限のセキュアなバージョンに、必要な依存関係をアップグレードします。
    3. アップグレードされた依存関係で PR を作成します。
  3. PR が承認されると、新しいブランチがベース ブランチとマージされます。
  4. マージされたブランチで、GitHub Actions の CI/CD タスクがトリガーされます。
  5. GitHub Actions によって、テスト環境またはステージング環境に新しいアプリ バージョンがデプロイされます。

考慮事項

GitHub DevSecOps ソリューションを Azure Well-Architected Framework の理念に一致させるには、このパターンの実装方法を決定する際に次の点を考慮してください。

コストの最適化

  • GitHub では、GitHub Actions について分単位で請求されます。 さらに、Actions ジョブをホストするオペレーティング システムの選択は、分単位の従量課金率と分単位のコストに影響を与えます。 可能な限り、Actions のホストには Linux を選択してください。 「GitHub Actions の支払いについて」を参照してください。
  • 多忙なスケジュールのプロジェクト マネージャーは、セキュリティ対策の追加によって、開発が遅れることに悩んでいる場合があります。 次のガイドラインに従って時間を節約することで、逆の体験をしてください。
    • テストを、ソース近くの左にシフトします。 結果として、チームはミスを減らすことができます。
    • 数か月後の運用環境ではなく、プログラミング中に問題に対処します。 それにより、開発者はコードの知識を更新する必要がありません。

オペレーショナル エクセレンス

  • 自動テストおよびメンテナンスは、脆弱性管理機能を使用する環境で実行します。これらの機能により、コードとその依存関係が自動的に変更されるためです。 自動テストでは、これらの変更に起因する問題が特定されます。

  • Azure Policy 機能を利用します。 デプロイとログ準拠の問題を拒否する以外に、これらのポリシーによって、リソースがそのようにデプロイされていない場合でも、リソースを変更し、それらを準拠させることができます。 たとえば、HTTP を使用するストレージ アカウントを Azure でデプロイしようとすると、Azure Policy によってその状況が検出されます。 その後、ポリシーによって、デプロイが自動的に変更され、ストレージ アカウントで強制的に HTTPS を使用させることができます。

  • Azure Resource Manager では、JSON テンプレートを使用して、デプロイに関連するリソースが記述されます。 チームは、バージョン管理、コード コラボレーション、CI/CD ワークフローなどの DevOps ツールを使用して、これらのテンプレート ドキュメントを管理することもできます。

  • DevSecOps に関する 1 つの懸念は、コード スキャンによって、偽陽性でいっぱいになったノイズの多い結果が生成され、次の種類の問題が発生する可能性があることです。

    • 開発者が、存在しない問題の調査に時間を無駄にする。
    • セキュリティの問題への対処によって、ワークフローが中断する。
    • 不正確なため、セキュリティ ツールの信頼が失われ、開発者が結果を無視する。

    これらの障害を克服するには、セキュリティをソフトウェア ライフサイクルに統合します。

    • IDE にスキャン チェックを埋め込む Codespaces のようなツールを採用します。つまり、開発者が使い慣れた環境でそれらを使用します。
    • セキュリティ チェックを、付け足しではなく、コード レビューの通常の部分にします。
    • 開発者に高精度のスキャンを任せて、ノイズの多いチェックはセキュリティ チームに任せます。

パフォーマンス効率

実行時間の長いアクションや複雑なアクション用に、CI/CD ジョブの独自のランナーをホストします。 それにより、強力な処理機能と十分なメモリを搭載したコンピューターを選択できます。 「セルフホスト ランナーについて」を参照してください。

[信頼性]

  • GitHub Enterprise Server で提供する GitHub.com のオンプレミスのデプロイを使用する場合は、回復性を強化するために高可用性フェールオーバー構成を使用します。
  • セルフホスト アクション ランナーを選択する場合は、それらを地理的に分散することを検討してください。

セキュリティ

  • パブリック リポジトリにセルフホスト アクション ランナーを使用することは推奨されません。 悪意のあるユーザーがリポジトリに参加し、ネットワーク内のコンピューターでアンセーフ コードを実行する PR を作成する可能性があります。 GitHub によってホストされるランナーでは、このリスクが解消されます。
  • CodeQL 分析エンジンを使用してコードをスキャンします。 CodeQL では、潜在的な脆弱性とコーディング エラーを検出できます。 それは、スケジュールに従って実行することも、コミットや PR の作成などのイベントが発生したときに実行することもできます。 「コード スキャニングについて」を参照してください。
  • Dependabot セキュリティ アップデートを構成してください。これにより、プロジェクトから既知の脅威を除去できます。
  • GitHub のコードスキャン機能を強化するには、Static Analysis Results Interchange Format (SARIF) ファイルを生成する GitHub のサードパーティ コード スキャン ツールを追加します。 その後、GitHub で、それらのツールによって潜在的なセキュリティ問題が特定されると、アラートが作成されます。

次のステップ