はじめに
セキュリティはアプリケーション開発後に考えるものだと思っていた私が出会ったのが「シフトレフト」という考え方です。このアプローチでは、開発の初期段階からセキュリティを意識し、プロセス全体にチェックと監視の仕組みを組み込みます。
この記事では、私が実際にDevSecOpsを導入し、AWSやSonarQubeなどのツールを使ってどのようにセキュリティ対策を進めたかを紹介します。具体的には、開発初期に取り組むべきセキュリティ対策や、実際に直面した課題とその解決策を解説します。
この記事を読むことで、DevSecOpsの基本から、実践的なセキュリティ施策まで学べる内容になっています。これからセキュリティを開発プロセスに組み込みたい方にとって、役立つ情報が満載です。
全体設計
参考
DevSecOpsを考える上で参考にしたのが、Webアプリケーションのセキュリティ向上を目的とした国際的な非営利団体、OWASP (Open Web Application Security Project)が策定している資料でした。
引用: OWASP Foundation, Inc. 『OWASP DevSecOps Guideline』
(https://owasp.org/www-project-devsecops-guideline/latest/00a-Overview)
整理
この資料より、開発フェーズごとに実施できるセキュリティ施策を洗い出し、施策を実施するためのツールやサービスを考えました。ツールの実行タイミングを含めて、整理した資料が次になります。
ツールの検証
洗い出したツールやサービスを１つづつ検証し、アプリケーションの開発フローに導入していきました。
📋 セキュリティチェックリスト
このリストは、過去のインシデントや誤りを繰り返さないようにすることを目的として作成されたチェックリストで、現場におけるこれまでのシステム開発で得たセキュリティに関する確認ポイントをまとめたExcelファイルです。
チェックリストを事前に確認することで、セッション管理が出来ているかなど、開発で必要なセキュリティ要素を意識しながらコードを書け、手戻りのない作業ができました。
ただ、現在開発中のシステムとリスト記載のものでは、フレームワークなどが異なり、チェックできない項目もありました。それでも、確認項目の中には、考慮になかった意外な項目があったため、とても参考になりました。
🏗️ AWS Well Architected Framework
AWS Well Architected Frameworkは、クラウドアーキテクチャの設計・運用における6つの柱（運用上の優秀性、セキュリティ、信頼性、パフォーマンス効率、コスト最適化、持続可能性）に基づいてシステムを評価するフレームワークです。マネジメントコンソールでツールを開き、チェックをつけると評価レポートを作成してくれます。
今回は、６つの柱のうち、セキュリティの柱の部分のみのチェックを行うことで、AWSが推奨するベストプラクティスに沿って、リソース全体を見直すことができました。セキュリティだけでなく、パフォーマンスや運用といった広い視点からシステムを評価できたのは、とても良い経験でした。
ただ、ベストプラクティスの背景や「なぜそうすべきなのか？」という部分を理解するには少し時間がかかりました。実際のプロジェクトでは、すべての推奨事項をそのまま取り入れるのが難しい場面もあるので、現実とのバランスを取りながら進めることの大切さも感じました。
[セキュリティのチェック結果画面]
🔧 Biome
BiomeはJavaScript/TypeScriptプロジェクト向けの高速なリンター＆フォーマッターで、ESLintやPrettierの代替として注目されているツールです。Biomeを選択した理由は、npmコマンドで導入でき、設定が簡単で処理速度が速いといった理由からでした。
コードを保存するタイミングでフォーマットを行い、パイプラインのビルド時にコードの文法チェックや型のチェックを実装できました。設定が比較的シンプルで、セキュリティ初心者の私でも無理なく導入できたのが印象的でした。
一方で、フォーマットの自動修正により、意図しない箇所で改行されることで、コードが見づらくなる点は少し不便な感じを受けました。
🏗️ cdk-nag
本プロジェクトでは、IaCツールにTerraformではなく、コードをTypescriptで書けるAWSのCDK（Cloud Development Kit）を使いました。
cdk-nagはAWS CDK（Cloud Development Kit）プロジェクト向けのセキュリティ・ベストプラクティス検証ツールで、IaCコードがAWSの推奨事項に準拠しているかをチェックする、AWS提供のnpmライブラリになります。
cdk-nagの導入で、インフラレベルでのセキュリティチェックにより、デプロイ前にリスクを特定できたのは大きな収穫でした。しかし、ちょっとした環境追加を行いたい時でも細かな設定を行わないと環境を作れなくなったのが残念でした。
[環境構築実行時のcdk-nagのエラー表示]
🔍 SonarQube
SonarQubeはソースコードの品質管理プラットフォームで、静的解析によりコードの脆弱性、バグ、技術的負債を継続的に検出・管理します。Dockerイメージで環境が提供されており、細かな内容については、同じチームのチームメンバーが記事を書いたのでそちらを参照してください。
SonarQubeはEC2にDockerで環境を構築し、デプロイパイプラインでSonarQubeを実行し、コードの静的コードチェックを実行するようにしました。結果はSonarQubeの中に保存されるのですが、APIで結果の情報が取得できるため、その情報を取得しメールで通知するようにしました。
静的解析により、同じコードの重複や、コメントしたまま放置されたコードなど、開発者が見落としがちなセキュリティ課題やコード品質の問題を自動的に発見できたのは良かったのですが、IaCでSonarQube構築時に一部設定が自動化できず、手で操作が必要だったのは少し手間に感じました。
[静的コードチェック実行時のメール]
[EC2に構築したSonarQubeのエラー表示画面]
📦 npm audit
npm audit は Node.js プロジェクトの依存関係に含まれるライブラリの既知の脆弱性を検出するためのnpm標準コマンドです。この「npm audit」コマンドをデプロイパイプライン内で実行することで、ライブラリに脆弱性がある場合はパイプラインを停止させ、デプロイしないといった制御ができました。
npm audit コマンドには脆弱性を自動修正するオプションがありますが、自動修正を実行するとアプリケーションが動かなくなることもあったため注意が必要です。
🕷️ OWASP ZAP
OWASP ZAP（Zed Attack Proxy）は、Webアプリケーションのセキュリティテスト用のオープンソースツールで、動的解析により実行時の脆弱性を検出します。ツールはDockerイメージで提供されており、1日1回時間起動でチェックのためのパイプラインを回し、パイプラインの中でDockerイメージ取得・脆弱性チェックを行い、レポートのURLをメールで通知。作成されたレポートを確認することで脆弱性診断結果を確認できるようにしました。
実際に稼働中のWebアプリケーションに対する動的なセキュリティテストにより、SQLインジェクションやXSSなどの実用的な脆弱性を検出できました。
しかし、公開しているWebサイトに対してセキュリティテストを行うため、本番環境への負荷や影響を考慮する必要がありました。また、テスト設定によっては想定外のページまでクロールしてしまうリスクもあったため注意が必要でした。
[レポートのURLを書いたメール]
[owaspzapのレポート]
🔥 WAF（Web Application Firewall）
続いて、アプリケーションのセキュリティを強化するために、AWS WAF（Web Application Firewall）を導入しました。WAFは、悪意のあるリクエストを検知・遮断し、アプリケーション層での攻撃からサービスを守るAWSのセキュリティサービスです。
Amplify（フロントエンド）とAppSync（バックエンド）のエンドポイントの前段にWAFを配置することで、SQLインジェクションやクロスサイトスクリプティング（XSS）といった一般的な攻撃からアプリを保護しています。
AWSマネジメントコンソール上から、IP制限やパターンマッチによるカスタムルールを簡単に設定できる点も扱いやすく、必要最低限のルールであれば短時間で導入できました。
一方で、WAFの効果がどの程度あるかについては、実際に攻撃を受けてみないと明確には分からないという側面があります。ログやメトリクスは取得できますが、本当に防御できているかの確証を得るには、シミュレーションやペネトレーションテストと組み合わせて運用していく必要があると感じました。
🛡️ SecurityHub + GuardDuty + Inspector
SecurityHubはAWSセキュリティサービスを統合管理するダッシュボードで、GuardDutyはAWS環境内の脅威を継続的に監視し、不正アクセスや異常な動作を検出するための脅威検出サービスです。Inspectorはアプリケーションの脆弱性を自動的に評価するサービスです。どのサービスもAWSのサービスになります。
これらのサービスを利用することにより、変更したリソース、または1日1回AWS全体のリソースのセキュリティ監視体制を構築できました。SecurityHubは個人で触れる機会が少ないため、今回の導入はよい学びとなりました。
ただ、問題のない警告を無視するように設定しても、結果の反映が1日後なので結果確認に時間がかかる点は、少しもどかしく感じました。
[SecurityHubのチェック結果画面]
🎯 まとめ
今回取り組んだDevSecOpsの内容について、社内のクラウドを専門に担当している部署のメンバーにレビューをしてもらったところ、「セキュリティに関して開発の仕組みに沿ってしっかり出来ている。」という嬉しい評価をいただきました。
DevSecOpsは一朝一夕で実現するものではありません。まずは、どういう施策が必要か全体を考え、少しづつできる所から導入していくことが大事だと思っています。ぜひトライしてみてください。
この記事が、皆さんのプロジェクトにおけるDevSecOpsの一助となれば幸いです。
Views: 0
