DevSecOps と CI/CD セキュリティガイドにようこそ。以下の各セクションで、みなさんのアプリケーションやインフラストラクチャのセキュリティ対策に役立つリソースをご覧ください。

目次

DevSecOps とは？

DevSecOps は、企画段階からデプロイまでにわたり、セキュリティを念頭に置いてアプリケーションやインフラストラクチャの開発を進めるという考え方です。DevSecOps を実現するには、開発ライフサイクルのあらゆる段階におけるセキュリティリスクを検討しなければなりません。従来の DevOps では、アプリケーションのビルド、テスト、デプロイの自動化のみに焦点を当てていました。DevSecOps ではこれに加え、スピードを下げずにセキュリティを高められるように、セキュリティ手法の自動化にも取り組みます。

図解で分かるDevSecOpsとは？

DevSecOps でセキュアな CI/CD パイプラインを実現する

現在、多くの企業にとって、セキュアな継続的インテグレーション & 継続的デリバリー (CI/CD) パイプラインは日常業務の一部になっています。パイプラインを適切にセットアップすれば、多くの手動タスクを自動化しソフトウェアの開発状況を可視化することで、デリバリープロセスの一貫性を維持できます。

ただし、CI/CD パイプラインはテクノロジースタックにおいて、インフラストラクチャからさまざまなリソース (開発環境や本番環境、分析キーやコード署名用の認証情報など) へのアクセスが行われるポイントでもあります。パイプラインからアクセス可能なリソース (セキュアシークレット、非公開コード、データベース) が増えるほど、CI/CD システムをセキュアに保つ重要性が高まります。

この記事では、CI/CD パイプラインのセキュリティを構成するさまざまな要素について説明するとともに、各要素の対策に役立つ方法も紹介します。

CI/CD セキュリティのベストプラクティスを構成する 3 つのカテゴリ

一般的に、セキュリティのベストプラクティスは、対応ソリューション別に 3 つのカテゴリに分けられます。具体的には、以下のとおりです。

1.パイプライン設定ファイルをセキュアにする 2.コードと Git 履歴を分析する 3.セキュリティポリシーを適用する

これら 3 カテゴリのうち、1 つとして軽視できるものはありません。各カテゴリの詳細と、それぞれへの対処方法を見ていきましょう。

パイプライン設定ファイルをセキュアにする

CI/CD パイプラインの設定を工夫することで、セキュリティ問題が発生するリスクを抑えられます。

まず、データベースやサードパーティサービスに接続するパイプラインで使用するシークレットは、安全に保管しましょう。CircleCI には、暗号化された状態で保存される環境変数と、コンテキスト機能が用意されています。コンテキストを使用すると、プロジェクト間で環境変数を共有できるようになります。また、組織管理者の設定により、コンテキストへのアクセスをセキュリティ グループのメンバーのみに限定することもできます。

サードパーティのソリューションにより、ジョブ用のセキュアなストレージからシークレットを直接フェッチするという方法もあります。ただし、許可した人物以外に認証情報を見られてしまう事態を防ぐために、リポジトリにプレーンテキストで認証情報を保存するのは避けてください。これは、リポジトリが非公開であっても同様です。

次に、コード署名キーなどの機密性の高いファイルを使う場合は、レイヤーを追加して暗号化済みファイルとリポジトリとを分離しましょう。サンプルはこちらをご覧ください。署名キーはリポジトリに暗号化して保存し、復号化キーは環境変数またはコンテキストに保存しましょう。また、キーの復号化を行うのは CI/CD ジョブ内とし、必要な場合のみに限定してください。こうすることで、機密性の高いファイルが部外者に見られたり、漏洩したりする事態はきわめて起こりにくくなります。

3 つ目として、CI/CD 環境を運用する際は必ず監視しましょう。シークレットが必要なジョブの完了時には、パイプラインで使用したコンテナや仮想マシン (VM) を必ず破棄するようにしてください。CircleCI では、Linux (Docker および Machine Executor)、macOS、Windows をはじめとするすべての対応プラットフォームでこうした破棄が自動で行われます。

最後に、リポジトリのフォークから送信されたプルリクエストについて、CI/CD システムでビルドを処理する場合には特に注意してください。ビルドステージの動作にシークレットを必須としている場合、パイプラインの設定によっては、フォークからのプルリクエストでもこのシークレットにアクセスできてしまいます。CircleCI では、フォークからのプルリクエストに対するシークレットの提供をデフォルトで禁止しています。

これら 4 つのポイントに対処すれば、CI/CD パイプラインの設定が原因でセキュリティインシデントが起きてしまうリスクを大幅に下げられます。次は、コードと Git 履歴の分析を考えましょう。

コードと Git 履歴を分析する

Git が開発者に人気を博している理由は、その変更履歴機能の幅の広さです。簡単な CLI コマンドでプロジェクトの履歴を調査したり、コード行を直近に変更したメンバーを特定したりと、さまざまな機能が備わっています。ところが、この幅の広さは同時に、Git リポジトリを公開している場合に Git 履歴のシークレットを攻撃者に見られてしまうということでもあります。シークレットを記載しないようにリポジトリを更新しても、この問題は防げません。

Trufflehog や GitLeaks などのツールを使用すれば、コードベースにコミットされたシークレットを特定できます。結果に応じて、該当のシークレットを無効化、ローテーションしてください。これらのツールでは、Git 履歴をスキャンして、過去にシークレットがリポジトリに追加された痕跡がないか検査できます。

Git 履歴にシークレットの痕跡がなければ、次の段階として、現在のリビジョンに脆弱な依存関係が含まれていないことを確認しましょう。

静的アプリケーションセキュリティテスト (SAST) では、コミットに含まれるアプリケーションを検査し、依存関係を分析します。依存関係に問題や既知のセキュリティ脆弱性が含まれている場合、コミットはセキュアではないものと判定され、デプロイは行われません。

動的アプリケーションセキュリティテスト (DAST) はさらに高度です。こちらでは、本番環境のコピーを CI ジョブ内でスピンアップし、コンテナや実行可能ファイルをスキャンします。このように動的に検査することで、SAST では検出できない、起動時に読み込まれる依存関係なども特定可能です。

セキュリティポリシーを適用する

セキュリティ問題の中には、既知の脆弱性を基に統計的にチェックすればよいものだけでなく、企業固有の問題もあります。このような問題はポリシーとしてコード化し、自動または手動でのコンプライアンスチェックとして対処する必要があります。

また、リポジトリにアクセス可能な全アカウントのリストの確認や、オンボーディングプロセスやオフボーディングプロセスのタイミング確認など、手動で行うしかないタスクもあります。これらのタスクの実行漏れがないように、定期的なリマインダーを設定することをお勧めします。

タスクによっては、すぐに自動化できるものもあります。たとえば、ルール一式を手軽にコード化し、CI/CD パイプラインに対して照合できるサードパーティのサービスがあります。こうしたサービスを利用すれば、データに関する規則が順守されているかを確認しやすくなるでしょう。規則違反があれば、ビルドが失敗するからです。

CircleCI Orb を使用して CI/CD パイプラインのセキュリティを強化する

CircleCI Orb は、ビルドに使用する CircleCI 設定ファイルをまとめた共有可能なパッケージです。Orb にはコマンド、Executor、ジョブを定義できるため、よく利用する構成内容を 1 行のコードにまとめ、再利用することが可能です。CircleCI の設定ファイルが再利用および共有可能なオープンソースパッケージとしてまとめられているので、さまざまなサービスをスピーディにパイプラインに組み込むことができます。これにより、設定不要なソリューションでセキュアなパイプラインを実現できます。

CircleCI Orb の詳細については、以下のブログ記事を参考にしてください。

CircleCI のプライベート Orb

従来のオープンソース版 CircleCI Orb は数千名の開発者の方々にご利用いただいていますが、大規模組織のお客様からは Orb を非公開にする手段が広く求められていました。そこで、CircleCI の全プランにプライベート Orb が導入されました。こちらは、開発の作業効率アップやチーム間のコラボレーションの促進に役立つだけでなく、高いプライバシー性も備えています。ガバナンスやコンプライアンスの基準が厳しい、ヘルスケアや金融などの業界のお客様には特にうってつけの機能です。

プライベート Orb を使用して、組織内でプライバシーを確保しながら効率よく共有を行う方法について詳しくは、「組織専用のプライベート Orb を開発する (英語)」に記載されているチュートリアルや、Orb に関するドキュメント をご覧ください。

CAS の 7 つのコンセプトでセキュアなコードの開発方法を身につける

継続的アプリケーションセキュリティ (CAS) は、開発現場でビルドの信頼性を高め、セキュアなアプリケーションや API を運用するための手法です。具体的には、文書に記されたセキュリティに関するポリシーやガイダンスを “コード化されたセキュリティ” に変換します。

CAS では、計装ベースでセキュリティを展開することにより、開発チーム、セキュリティチーム、運用チームが一丸となり、モダンなソフトウェア開発のペースに遅れることなく大規模な作業を行えます。CAS のコンセプトの実施方法について詳しくは、こちら をご覧ください。

DevSecOps の手法を取り入れる

みなさんのセキュリティの現状を調べるうえで最も重要な存在は、みなさんのチームメンバーです。みなさんのアプリケーションを最もよく知り、日々扱っているからです。こうしたメンバーを支援する方法としては、以下のものが挙げられます。

  • セキュリティの問題について、メンバー向けに明快な報告プロセスを設定する
  • セキュリティ上の欠陥が特定された場合、修正のための時間を割り当てる
  • 問題を包み隠さず報告したメンバーを褒め称える

現在、チームのメンバーが不審な活動を報告するのにかかる手間について考えてみてください。注意喚起のために Slack の複数のチャンネルに投稿する必要はあるでしょうか？そのような問題の調査を始めるまでのプロセスにムダはないでしょうか？また、報告された問題が誤検出だとわかった場合の対応も振り返ってみてください。チームの時間をムダにしたと責めてはいませんか？それとも、失敗が他のメンバー全員の教訓になるように、報告者を責めずに事後分析を行っていますか？チームにセキュリティ重視の開発文化を根付かせられるかどうかは、こうした対応の検討にかかっています。

ぜひ、「DevOps から DevSecOps へ移行するための 3 つのルール」をご覧ください。

本記事では、CI/CD パイプラインのセキュリティを高められる、標準的なセキュリティ対策を多数ご紹介しました。さらに、CI/CD パイプラインを駆使すれば、セキュリティ脆弱性の検出からパッチ適用までも自動化できます。興味のある方は、「CI/CD で脆弱性管理と DevSecOps を実現するには」もあわせてご覧ください。