安全性とコンプライアンスを維持しながら、開発者の生産性とコラボレーションを可能にする方法をご紹介します。ビジネスを停滞させることなく、コンプライアンスを維持します。セキュリティからCI/CDまで、ソフトウェアワークフローのあらゆるステップを自動化することで、開発者は最も重要な「構築」に集中することができます。

前回のブログ「コンプライアンスの基礎を固める」では、開発者がコンプライアンスに対応できるようにするための基礎知識を紹介しました。

本日は、開発者の生産性と満足度を高めながら、企業文化を変革することなくコンプライアンス要件を満たすための 3 つの実践的な方法について説明します。

1.基本的なことをきちんと、頻繁に行う

コンプライアンス要件に対応するための最初の方法は、非常に単純であるため、見過ごされがちです。金融、自動車、政府機関、ハイテクなど業種を問わず、開発者のワークフローや企業文化の一部として、コンプライアンスを迅速に達成するための基本的な方法があります。

コードレビュー

クリーンなコードを書くために重要なのは、コードレビューです。しかし、反復可能で追跡可能なコードレビュープロセスを持つことは、コンプライアンスプログラムの基礎となる要素でもあります。これにより、ソフトウェアのデリバリーにおけるリスクが早期に発見され、緩和されるとともに、将来のレビューのために監査可能であることが保証されます。

GitHubでは、何百万人もの開発者が毎日利用しているプルリクエストが既存のワークフローの一部となっているため、コードレビューが容易になっています。GitHubはまた、コンプライアンステスターや監査役がプルリクエストをレビューするのも簡単で、一元化された場所にある不変の監査ログにアクセスすることができます。

職務の分離

企業によっては、職務の分離とは、トランザクションやプロセスを手動で管理しすぎている人のことだと定義されていることがあります。これは、最新のクラウドネイティブのプラクティスを導入する際に、不安になる可能性があります。

ありがたいことに、職務分掌に対するより現代的なアプローチをサポートする業界からのガイダンスがあります。 PCI-DSS 要件ガイドでは、個人という用語を使用せず、機能とアカウントに焦点を当てることで、よりクラウド ネイティブに適したアプローチを提供しています。

「この要件の目的は、開発およびテスト機能を本番機能から分離することです。例えば、開発者は開発環境では昇格した特権を持つ管理者レベルのアカウントを使用し、本番環境にはユーザーレベルのアクセス権を持つ別のアカウントを持つことができます。"とあります。

このアプローチは、クラウドネイティブの12ファクターアプリケーションの方法論とよく合致しています。Build, release, run factorの説明では、「各リリースは、ビルド、リリース、実行の各段階において厳格な分離を実施する必要があります。各リリースには一意のIDが付与され、ロールバック機能をサポートする必要がある "とあります。チームは、機能の分離と一意のIDへのトレーサビリティがある限り、手動でコントロールしすぎる人を心配することなく、生産へのデリバリーを完全に自動化することができます。さらに、PCI-DSSのような業界のベストプラクティスや要件に沿ったものであることが保証されます。

職務の分離を可能にするためには、明確なアイデンティティとアクセス管理戦略を持つ必要があります。ありがたいことに、車輪の再発明をする必要はありません。GitHub Enterprise には、開発環境全体へのアクセスを管理するためのオプションがいくつか用意されています。

• 企業向けのSAMLシングルサインオンを設定することができます。これは追加チェックで、ユーザーの真正性を自社の ID プロバイダーに対して確認することができます (ただし、自社の GitHub アカウントはそのまま使用します)。
• そして、チームのメンバーシップをID プロバイダーのグループと同期させることができます。その結果、ID プロバイダでグループのメンバーシップを変更すると、GitHub のチーム・メンバーシップ (および関連するアクセス権) も更新されます。
• あるいは、GitHubEnterprise Managed Users(EMUs)を採用することもできます。これはGitHub Enterpriseの一種で、IDプロバイダを通じて一元管理されたアカウントでのみログインできる。ユーザーは個人アカウントでGitHubにログインする必要はなく、会社のリソースにアクセスするためにシングルサインオンを使用することができます。(これについては、EMUの探索とそれがもたらすメリットについて、こちらのブログ記事をご覧ください)。

AIを活用したコンプライアンス

前回のブログでは、AIを活用したコンプライアンスと、セキュリティ、製造業、銀行における既存の機会のいくつかを簡単に取り上げました。また、コンプライアンスの基本をさらに最適化する可能性のある機会がいくつか控えています。

生成的なAIツールを活用することで、ユニットテストを独自に作成し、宣言型DevOpsワークフローで職務分離が確実に実施されるようになる可能性は十分にあります。 生成的AIの非決定的な性質のため、実行するたびに異なる結果が出るかもしれませんし、ユニットテストにはまだ誰も思いつかないようなリスクシナリオが含まれるかもしれません。これによって、真のリスクベースコンプライアンスを驚くほど高めることができるのです。

デリバリーにおいてコンプライアンスによく取り組むことの大きなメリットの1つは、信頼度の向上です。しかし、信頼を定量化することは非常に難しく、特にディープラーニングソリューションを活用したいと考えている規制された業界内では困難です。これは、継続的なコンプライアンスを可能にするだけでなく、企業がビジネス価値を向上させる新しいテクノロジーを導入する際にも役立ちます。

ディペンデンシー・マネジメント

企業は、サプライチェーンにおいて、オープンソースソフトウェアへの依存度を高めています。その結果、依存関係管理のための最適化された、繰り返し可能で可聴な管理は、あらゆる業界のコンプライアンスプログラムの基礎になりつつあります。

GitHubの観点から、Dependabotはあなたのサプライチェーンが安全であるという確信を提供することができます。Dependabotを設定すると、開発者はセキュリティ上の脅威が発見されるとすぐに警告を受け、通常のワークフローで対策を講じることができるようになります。

Dependabotを活用することで、既知の脆弱性を持つソフトウェアの依存関係をリポジトリが使用した場合、不変かつ監査可能なアラートを受け取ることができます。プルリクエストは、開発者またはセキュリティチームによって起動され、将来のレビューのために監査可能なアーティファクトの別のセットを与えることができます。

承認

ほとんどの組織には承認プロセスがありますが、時間がかかったり、プロセスの後半で発生したりすることがあります。Google は、DORA 2019 state of DevOps レポートの結果に基づき、ピアレビューが変更承認プロセスの合理化に役立つと説明しています。

デリバリーパイプラインには、リリース前の要件のサインオフ、テスト結果、セキュリティレビュー、本番運用準備の確認など、承認が必要な管理ポイントが多数存在する可能性があります。

社内の体制や連携に応じて、プロセス全体のさまざまな段階でチームにサインオフを求めることができます。ビルドとテストの段階では、プルリクエストで手動承認を行うことで、必要なレビューを収集することができます。

ビルドとテストが完了したら、コードをインフラストラクチャにリリースする時が来ました。デプロイメント・パターンと戦略について話すことは、この記事の範囲外です。しかし、デプロイメントプロセスの一部として、承認が必要になる場合があります。

これらの承認を得るために、デプロイメントに環境を使用する必要があります。環境は、デプロイメント ターゲット（ステージング、テスト、本番など）を記述するために使用されます。環境を使うことで、GitHub Actions がデプロイを開始する前に手動で承認を得ることができるようになります。

どちらの場合も、必要な承認回数を決める際にはトレードオフの関係にあることを忘れないようにしましょう。必要なレビューの数を多く設定しすぎると、手作業が必要になるため配信のペースに影響が出る可能性があります。可能であれば、チェックを自動化して手動によるオーバーヘッドを減らし、全体的な敏捷性を最適化することを検討してください。

2.コンセプトと用語の共通理解

これもまた、当たり前のことのように聞こえるので、見過ごされるかもしれません。しかし、開発者やDevOps、クラウドネイティブの実務者が日常的に使っている概念や用語で、コンプライアンステスターや監査人がまったく理解できないものは、おそらくたくさんあるはずです。

2015年のことですが、The Phoenix Projectの著者であるGene Kim氏と他の数名の著者が、DevOps Audit Defense Toolkitを作成しました。最初のブログで述べたように、この文書の目的は、"IT管理者と実務者が監査プロセスについて教育し、監査人に対して、ビジネスリスクを理解し、そのリスクを適切に軽減していることを証明できるようにする "ことでした。しかし、何から始めればいいのでしょうか？

以下に、GitHubに関連する管理目標に関する基本的な用語のチートシートと、コンプライアンス、規制、リスク、監査などの世界とのマッピングを示します。開発者とコンプライアンスや監査担当者の間で共通の理解を得るためのよいきっかけになるでしょう。

これをまとめるために、GitHub Enterprise CloudとAdvanced Securityの経済効果に関する最新のForresterレポートに、開発者とコンプライアンステスターや監査人の間で共通の理解が得られるという利点の素晴らしい例が示されています。 このレポートでは、開発者と監査人の両方に役立つ自動化された文書化プロセスの利点の1つを強調しています。

"これらの新しい標準化された文書構造により、監査人はコンプライアンスに必要な文書を容易に見つけ、まとめることができるようになりました。このため、インタビューに応じた組織は、業界のコンプライアンスやセキュリティ監査に備える時間を節約することができました。"

3.開発者が 3 つの防衛ラインのどこに当てはまるかを理解できるようにする

3つの 防衛ラインは、リスクマネジメントとガバナンスに使用されるモデルです。このモデルは、リスク対策に関わるチームの役割と責任を明確にするのに役立ちます。

エンドユーザーにソフトウェアを出荷し続けるエンジニアリングチームとエンジニアリングリードは、第一の防衛ラインであると考えましょう。このチームが、自分たちのソリューションの中にあるリスクを特定するための適切なレベルのスキルを持っていることを確認することは、非常に重要です。

第二の防御ラインは、通常、組織レベルのフレームワーク、ポリシー、およびツールによって、大規模に達成されます。これは、第一の防衛線がリスク軽減のための手法をどれだけうまく導入しているか、組織全体で一貫してリスクを測定し、定義しているかを監視する役割を果たすものである。

内部監査は、第三の防衛ラインです。レッドチームとブルーチームが互いに補完し合うように、内部監査は3つの防衛ラインの最後のパズルピースと考えることができる。内部監査は、リスクマネジメントとガバナンスの有効性を評価し、経営幹部や外部の規制当局と連携して、実行されている統制の意識を高める。

例えてみましょう。ホッケーチームは、単にゴールを決めるだけでなく、自分たちに対するゴールを防ぐために構成されています。

• フォワード：彼らはゴールを決めたり、ゴールをアシストしたりするために存在する。しかし、彼らはディフェンスの他のポジションと連携するよう求められることもあります。ディフェンスの第一線と考えましょう。彼らの仕事は、ビジネス価値を提供し、かつ安全なソリューションを作ることです。
• ディフェンダー: 主な役割は、明らかにゴールを防ぐことです。しかし、現在の優先順位（オフェンスかディフェンスか）については、フォワードとパートナーを組みます。彼らは第二の防衛ラインのようなもので、リスクの監視を行い、エンジニアリングチームと協力します。
• ゴールテンダー：最後の防衛ライン。内部監査に相当するものと考えることができる。 フォワードやディフェンダーとは独立した存在で、異なる責任、ツール、視点を持つ。

ホッケーのチームで、フォワードは非常に強いが、ディフェンスとゴールキーパーが弱いチームは、ほとんど成功しない。 また、ディフェンスが強くてもオフェンスが弱いチームも、成功することはほとんどない。成功するには、3つの側面がすべて調和していることが必要なのです。

これはビジネスでも同じです。もし、あなたのソリューションが顧客の要求を満たしていても、安全でなければ、あなたのビジネスは失敗に終わります。安全性が高くても、使い勝手が悪かったり、価値を提供できなかったりすれば、それは失敗に終わります。成功は、価値とリスク管理の適切なバランスを見つけることによって達成されます。

開発者は、自分たちのチームのためにゴールを決めること、つまり私たちの世界を動かすソフトウェアを作ることが目的であることを理解できます。 しかし、開発者はチームの防御能力をサポートし、ソフトウェアの安全性を確保する必要があります。彼らの成功は、より広いチームの成功に依存しており、新たな責任を負う必要はないのです。

次のステップ

ここまで、開発フローにコンプライアンスを導入する方法をご紹介してきました。ブランチ保護ルールや プルリクエストから、CODEOWNERSや環境承認まで、GitHub にはコンプライアンスに自然と集中できるような機能がいくつもあります。

これは、問題解決のための一歩に過ぎません。コンプライアンスとDevOpsの実践者の間で共通言語を持つことは、実施された対策を示す上で非常に重要です。その共通言語があれば、誰もがコンプライアンスについて考えなければならないことは明らかであり、エンジニアリングチームは3つの防衛線の一部なのです。

このシリーズの次回は、開発者のワークフローでコンプライアンスを確保する方法について説明します。

安全性とコンプライアンスを保ちながら、開発者のスピードとコラボレーションを向上させる準備はできていますか？GitHub Enterprise がどのように役立つかをご覧ください。