DevSecOps パイプラインを構築してみよう !
高野 秀樹
こんにちは、builders.flash セキュリティシリーズの 3 作目を担当させていただきます、ソリューションアーキテクトの高野です。普段は製造業のお客様担当として、スマートプロダクトの開発支援や、SaaS plus a box といったモノとコトを組み合わせた新たなビジネス創出のお手伝いなどをさせていただいています。最近はこのような SaaS ビジネス関連の AWS イベント を実施しておりますので、ぜひご興味のある方はご覧ください。
新たなビジネスを創出する際には、市場の要求に迅速に応えるための開発スピードが求められますが、同時にプロダクトの品質もサービス展開のブロッカーにならない様に担保される必要があります。セキュリティもその重要な一要素です。
昨今では開発プロセスにおいて DevOps とセキュリティテストを組み合わせた DevSecOps という言葉が一般化しており、リリースの頻度とセキュリティの両立は、多くの開発者や運用者、また事業企画者にとって、少なくとも頭の片隅にはある状況になりつつあると思います。一方で、CI/CD Pipeline に自動化された Security Testing を組み込むにあたって、まず何から始めれば…といった方も依然多いのではないでしょうか。
そこで今回は、AWS が公開している、CI/CD Pipeline の中に複数の Security Testing を組み込む AWS 上での方法をご紹介するハンズオンを題材として、全体の流れを簡単におさらいしつつ、想定されるユースケースに沿ってカスタマイズしながら、理解を深めていただければと思います。
このシリーズ記事のその他の記事はこちら
- 選択
- ビルダーのビルダーによるビルダーのためのセキュリティ »
- セキュリティを何から始めれば良いか分からない開発者の方へ »
- DevSecOps パイプラインを構築してみよう ! »
- Amazon Inspector と AWS Systems Manager を用いて脆弱性の修復パイプラインを構築しよう
- マルチテナント SaaS アプリケーションの認証を Amazon Cognito で実現してみよう !
- すぐに始めて、継続できる AWS のセキュリティ対策
ご注意
本記事で紹介する AWS サービスを起動する際には、料金がかかります。builders.flash メールメンバー特典の、クラウドレシピ向けクレジットコードプレゼントの入手をお勧めします。
このクラウドレシピ (ハンズオン記事) を無料でお試しいただけます »
毎月提供されるクラウドレシピのアップデート情報とともに、クレジットコードを受け取ることができます。
Security for Developers ハンズオンのご紹介
AWS の Developer Accelerate (DevAx) チームによる DevAx::Academy プログラムの一環である、「Security for Developers」というハンズオンコンテンツです。こちらの図の CODE, BUILD, TEST といったフェーズにおいて、CI/CD の中に自動的なセキュリティテストを組み込むといった内容で、今回はこちらを題材とします。
ハンズオンの設定自体は通常 1.5 ~ 2 時間ほどで実施できます。注意点として、ハンズオン実施において用いられているテストツールは全て OSS ですので無償になりますが、AWS リソースについては費用がかかりますので、環境を残しておく特段の理由がない場合は最後の後片付けを忘れずにご実施ください。また、商用利用の場合には SCA ツールである Safety の有償版が必要になる点ご注意ください。
クリックすると拡大します
ハンズオンの流れのおさらい
では、本題に入っていきます。まず、ハンズオンの全体の流れは以下の図のようになっています。
① CI/CD パイプラインおよびテストに必要なツールが動作する環境は、AWS Cloud Development Kit (CDK) により構築されています。AWS CDK のソースコードは AWS Cloud9 環境における pipeline ディレクトリ内で定義されており、cdk deploy により環境が払い出されます。AWS CDK についてより詳細に把握されたい場合は、AWS CDK User Guide や AWS CDK Reference をご参照ください。
AWS Cloud9 が利用できない場合、こちらのブログ をご参考に AWS IDE Toolkits または AWS CloudShell をご利用ください。
② Cloud9 環境で、脆弱性などの問題を含む Web App を取得します。ソースコードは Cloud9 環境の flask-app ディレクトリにダウンロードされます。このディレクトリ内には Web App のソースコードの他、一連のセキュリティテストツールにおける AWS CodeBuild によるテストの実行方法を定義した buildspec.yaml も含まれています。
③ ①でプロビジョンした AWS CodeCommit のリポジトリに Push することで、CI/CD パイプラインおよび一連のセキュリティテストがフックされ、SAST (Static Application Security Testing), SCA (Software Composition Analysis), License Check, DAST (Dynamic Application Security Testing) の順に実行されます。
④ このアプリケーション内には多くの脆弱性、古いバージョンのパッケージ、プロジェクトの戦略上使用すべきでないライセンスを使用したライブラリが含まれており、それぞれのテストにおいてこれらの問題が検出されます。
⑤ このハンズオンでは、最初から全てのセキュリティテストは有効化されておらず、③と④で問題を修正しながら後段のテストツールの設定と有効化をしていきます。そして、再度③のリポジトリへの Push を再実施し、④新たなテストで明らかになった脆弱性の修正、⑤後段のテストの設定と有効化を繰り返していくことで、最終的にテスト全体が正常に実施され、アプリケーションで検知された全ての問題を修正することができる、といった流れになります。
ここで、上記の DevSecOps パイプラインでは、CodeCommit への Push 後の自動的なセキュリティテストを扱っていますが、一方で、リポジトリへの Push 後だけではなくより早期のフェーズにおける脅威検知によって、修正コストがさらに削減できるといったプラクティスがあります。例えば、アクセスキーやシークレットなどの機密情報をハードコードしたまま commit が通ってしまい、その後のテストで問題が明らかになるよりは、コーディング中に脅威を検知できる方が、修正コストやリスクの観点でもメリットがあるはずです。
前回の記事 においても、コードディング中のセキュリティチェックとして IDE プラグインや Pre-Commit hook といったトピックについて紹介されていました。そこで、今回はこの DevSecOps パイプラインのカスタマイズとして、前段に Pre-Commit hook を導入してみたいと思います。
Pre-Commit hook の導入
よく用いられるツールとして Talisman や git-secret などがあり、今回は前者の Talisman を用います。本記事では、Pre-Commit hook をハンズオンで用いられているソースコードに対して導入しますので、準備段階として上図の「② Web App を取得」までが少なくともできている状態まで実施してください。その後、下記の方法で、ハンズオンで用いている Cloud9 環境に Talisman をインストールします。
sudo yum install perl-Digest-SHA -y
curl --silent https://raw.githubusercontent.com/thoughtworks/talisman/master/global_install_scripts/install.bash > /tmp/install_talisman.bash && /bin/bash /tmp/install_talisman.bashインストールの際にはいくつか初期設定の入力が必要です。TALISMAN_HOME の設定は以下のように 1 を選択してください。
インタラクティブモードの選択では y を入力します。
次に、セキュリティ脅威の分析を行う対象の git レポジトリとして以下のパスを入力します。
/home/ec2-user/environment/flask-appこれで、Talisman のインストールは完了します。
次に、Talisman が report として出力する脅威の severity (重要度) の threshold を設定します。デフォルトは low となっていますが、今回のハンズオン用のコンテンツの場合、簡便のためにおいている内容にも反応してしまうので、今回は medium に変更します。皆様のアプリケーションの状況や実装に応じて切り替えていただくことを推奨します。
echo 'threshold: medium' > ~/.talismanrc次に、動作確認のために、本来はハードコードすべきではない、aws のアクセスキーとシークレットキーをハードコードしてみます。/home/ec2-user/environment/flask-app/app.py に挿入します。このとき、Ctrl + s などで変更を保存するのを忘れないでください。
aws_access_key = "XXXX"
aws_secret_key = "XXXX"
そして、以下のコマンドでリポジトリへのコミットを試します。
cd /home/ec2-user/environment/flask-app
git add .
git commit -m"added secret pattern"すると、秘匿性の高い文字列を検知し、severity : high (重要度 : 高) でレポートが出力され、コミットが停止されます。このように、Pre-Commit hook ではコミット前にセキュリティを検知しますので、git push でリモートリポジトリに反映してしまう前に潜在的な脅威を検知することができます。
クリックすると拡大します
では、次にこちらのように /home/ec2-user/environment/flask-app/app.py に挿入した文字列を削除します。このとき、Ctrl + s などで変更を保存するのを忘れないでください。
クリックすると拡大します
もう一度コミットを試してみましょう。
cd /home/ec2-user/environment/flask-app
git add .
git commit -m"removed secret pattern"以下のように、Talisman の Scan が正常終了し、コミットが成功します。
まとめ
いかがでしたか ? 今回紹介した Security for Developers ハンズオンは、自動化されたセキュリティテストを含む CI/CD パイプラインを AWS 上で試しに構築する際に大変有用ですので、是非実施いただければと思います。また、AWS CDK を用いた、AWS Code シリーズによる CI/CD プロセスのプロビジョン方法は、実際のプロジェクトにも参考になると思います。
皆さんが担当されるプロダクトにおいても、想定されるセキュリティ脅威に応じたテストプロセスやツールを策定した上で、AWS を活用し DevSecOps パイプラインを効率的に実現しましょう！
このシリーズ記事のその他の記事はこちら
- 選択
- ビルダーのビルダーによるビルダーのためのセキュリティ »
- セキュリティを何から始めれば良いか分からない開発者の方へ »
- DevSecOps パイプラインを構築してみよう ! »
- Amazon Inspector と AWS Systems Manager を用いて脆弱性の修復パイプラインを構築しよう
- マルチテナント SaaS アプリケーションの認証を Amazon Cognito で実現してみよう !
- すぐに始めて、継続できる AWS のセキュリティ対策
筆者プロフィール
高野 秀樹
アマゾン ウェブ サービス ジャパン合同会社
シニアソリューションアーキテクト
製造業で Web / Mobile App 開発、音楽情報処理に関する技術開発、新規事業企画開発などを経て AWS に入社。製造業のお客様を担当するソリューションアーキテクトとして技術支援に取り組んでいます。
最近はシティポップという日本の音楽ジャンルが世界的に認知されてきています。楽曲もさることながら、私はシティポップの CD でよく見るジャケ画にハマっています。
AWS を無料でお試しいただけます