セキュリティを何から始めれば良いか分からない開発者の方へ

業務の中で、「セキュリティは大丈夫ですか ?」と質問されたり、「セキュリティを万全にしてほしい」と言われたご経験のある方は多いのではないでしょうか ? その時、誠実に回答しようとすると難しさがあると思います。例えば

「使っているフレームワークは最新化しているし、コーディングのベストプラクティスに沿っている」
「WAF やセキュリティスキャンを実行して脆弱性や攻撃を検知できるようにしている」

と回答できるかもしれません。けれども、それで "大丈夫" と言い切って良いものか、モヤモヤしてしまうのではないでしょうか ?

実は「セキュリティを万全にしてください」という要求はそれだけでは不十分です。現代において、ソフトウェアは日々更新され、そして残念ながら同様に攻撃者も日々様々な攻撃方法を試し、生み出しています。この状況において、全てのセキュリティの問題を解決できる銀の弾丸は現時点ではありません。しかし、私たちがセキュリティの対応や実装のためにかけることができるコストや時間は限られています。

そのため、みなさんのシステムでセキュリティを必要十分に実装するためには、

「何を」
「どんな脅威から」
「どのようにして」

守るのかを具体的に定義して、限られたリソースを適切に投入する必要があります。

「セキュリティは大丈夫ですか ?」という質問の中にはこのような具体性がありません。これは、システム開発において、要件が不確定であるという状況ととても類似しています。開発者の皆さんは何かを作るのが好きで、それにやりがいを感じているからこそ、この仕事を選ばれていると思います。しかし、要件が曖昧で、何を作れば良いのか分からない中では、開発のモチベーションが上がらず、効率的に素晴らしいものを開発することはできない、ということもよくご存知でしょう。

セキュリティでもこれは同じです。「セキュリティを万全にしてください」という要求は、具体性がなく、曖昧な要件と同じです。これでは、みなさんも具体的に何をすれば良いか分からず、モチベーションが下がってしまうのではないでしょうか ?
これが、開発者の方がセキュリティに苦手意識を持つ、1 つの理由ではないでしょうか。

脅威モデリングは設計時に潜在的なセキュリティの問題を特定し、リストアップする方法です。

自分たちのアプリケーションやサービス、開発しているモジュールに対して、どんな脅威が考えられ、それに対して影響度や、どのような対応方法、軽減策があるかを整理することで、優先度をつけて具体的な対応策を考えることができます。
下記のような情報をリストにまとめ、セキュリティ要件の特定をしていきます。

• アセット / アクター / エントリポイント / コンポーネント / 信頼レベル
• 脅威のリスト
• 脅威ごとの軽減策

これらをもとに、リスクマトリクスを作成し、脅威に対して適切な対応が行われているかを確認していきます。

次の図は脅威モデリングの例です。
また、より詳しい脅威モデリングの方法については、AWS ブログの 脅威モデリングのアプローチ方法 もご覧ください。

実際に脅威を洗い出す際には下記のような脅威のリストやセキュリティのガイドラインを参考にすることをお勧めします。

• IPA 情報セキュリティ10大脅威 2022
• IPA 安全なウェブサイトの作り方
• OWASP Top 10
• OWASP Serverless Top 10

セキュリティの要件が具体的になったら、次はセキュリティをどのように実装していくかを考えなければいけません。しかし、具体的な実装方法はセキュリティ要件によるのでこの記事で扱いきれません。一方で、セキュリティのチェックなどのプロセスは自動化を導入することで効率化することができます (開発者の皆さんは自動化は大好きですよね ?)。

そこで、ここからは皆さんの開発環境にも導入できる、自動的なセキュリティチェックの方法やプラクティスを紹介していきたいと思います。

皆さんが普段利用されている IDE に snyk などが提供するセキュリティプラグインを導入することで、コーディング中からセキュリティの課題を発見し、不具合を作り込んでしまうことを防ぐことができます。これらのプラグインは通常、正規表現などを利用してソースコード上にセキュリティ上の問題のある実装が行われていないかをチェックし、迅速に開発者にフィードバックを提供してくれます。

ただし、あくまでも開発者への迅速なフィードバックを目的としているものであるため、この後紹介する別のフェーズでのアプローチと組み合わせて利用することをお勧めします。

コーディング中の情報漏洩の中で、アクセスキーやシークレットトークン、キー情報などをハードコードしたまま、git リポジトリにコミットしてしまうというトラブルはよくある失敗です。Talisman や git-secret などの Pre-Commit フックを利用することで、機密データが誤って git にコミットされることを防ぐことができます。

上記のようなツールを使ったチェックは便利で、迅速なフィードバックを得ることや、単純なミスを防ぐためにはとても有用ですが、全ての問題を見つけて防ぐことができるわけではありません。経験豊富な開発者によるレビューは、ツールでは見つけづらい問題を発見したり、コード全体の品質を高めるためにも非常に効果的です。正しいプラクティスに沿った実装は多くの場合セキュリティを強化することにもつながるため、コードレビューはセキュリティにとっても価値のある活動と言えます。

一方で、コードレビューには工数がかかってしまい、特に熟練の開発者には難しい機能の実装などより価値を生み出す作業に多くの時間を費やしてほしいということも事実です。

Amazon CodeGuru Reviewer は AI によるコードレビューにより、レビュアーに負担を減らし、レビューを受ける側も迅速なフィードバックを得ることができるため、コードレビューをより効率的に行うことができるようになります。また、Security Detector というセキュリティに関する検出器により、セキュリティの問題の検査も可能です。

この機能についてより詳しく解説した記事が、こちら で公開されておりますので合わせてご覧ください。

ビルドも成功し、実際にアプリケーションを動作させてテストを行うフェーズまで到達した場合、セキュリティのテストも動的アプリケーションセキュリティテスト (DAST) として実施することができます。

これまでの静的なチェックでは発見できないような、システムを結合して実際に動作させた際の挙動から発生する脆弱性など、実行時の問題を発見するために有用なテストです。OWASP ZAP (Zed Attack Proxy) などを使うことで実施することができます。

SAST の結果と比較して、誤検出や検出漏れをチェックしていくことで、より効果的になります。

ここまでご紹介してきた、SAST や DAST を CI/CD のパイプラインに組み込みことで、セキュリティテストを自動化し、開発中に迅速なフィードバックを得て、継続的にアプリケーションのセキュリティを強化していくことができます。AWS の開発者向けサービスである、Code シリーズで実現する場合、CodepPipeline で作成されたパイプラインの中で、CodeBuild から各ツールの分析やテストを実行することでこれを実現することができます。

実際に CodeBuild から SonarQube でのコード解析を実行し、SAST を行うサンプルの buildspec.yaml の例を紹介しておきます。

このコードでは下記の環境変数を定義しています。

このような構成を実際に AWS 上で試してみることができる ハンズオン も公開されています。

いかがでしたか ? 開発者の方にとってセキュリティは「大事なのはわかっているけれど何をしたら良いかよくわからないもの」であるために、面倒に思ってしまったり、難しく感じている面があるのではないでしょうか ?

しかし、実際はセキュリティもこの記事でご紹介した脅威モデリングなどのプロセスによって具体的な "要件" として定義していくことが可能です。そうして具体的な課題になれば、ものづくりを愛する開発者の皆さんにとっては、どう解決すれば良いかを考え、実装していく興味深い対象に見えてくるのではないでしょうか ?

またセキュリティの実装について、自動化によってライフサイクルの中でチェックしていくことで、継続的な改善もしやすくなってくるはずです。ぜひ、皆様の環境で実現しやすいところから取り組んでみてください。

この記事が、セキュリティに対して、苦手意識のあった開発者の方にとって、チャレンジのきっかけになれば嬉しく思います。「こんな取り組みしたよ」という取り組みがあればぜひ「#AWSウェブマガジン」タグをつけて投稿いただくか、勉強会などで紹介してみてください。