この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
今回はAWS Builders Online Seriesの中から「(私のように)セキュリティを何から始めれば良いか分からない開発者の方へ」というセッションを視聴しました。
AWS Builders Online SeriesとはAWS初心者向けのオンラインイベントです。
- AWSについてこれから学んでいきたい方
- 初心者向けのテーマを短時間でサックっと勉強したい
という方にピッタリなセッションがたっぷり用意されています。今回私が受講した「(私のように)セキュリティを何から始めれば良いか分からない開発者の方へ」というセッションはLevel 200となっていてトピックの入門知識を持っている方を対象にしたセッションになります。
こちらのセッションを受講してみたい方は下記からアーカイブを視聴することができます。
セッションについて
概要
クラウドでのアプリケーション開発でもセキュリティは開発者にとって最も重要かつ最も気が重いテーマです。重要性は分かっていても何から始めて良いかわからない、という方も多いでしょう。しかし、開発者の皆さんはタスクを自動化して効率化するのは大好きだと思います。このセッションではクラウドとそのサービスが提供する機能を活用して、セキュリティも自動化しながら、前向きに向き合っていくためのヒントをご紹介します。
登壇者
アマゾンウェブサービスジャパン合同会社 ソリューションアーキテクト 金森政雄 氏
セキュリティを明確にする
セキュリティを面倒だと思ってしまう理由
上司やお客様から「セキュリティよろしく！」と言われても、広すぎて何のセキュリティの話をしたいのか分からない。一般的なセキュリティ対応はしているし、脆弱検査性等もしているが100％セキュアにするにはどうしたらいいのかわからない。こういった思いを持つ開発者は少なくないと思います。
何らかの形でセキュリティへの対策はしているけれど、何が求められているか分からないという問題がこうした思いを生んでいます。
「セキュリティを強化する。」といった曖昧な要求のままでは、どう進めていいか分からないという状況が起きてしまいます。
要求を明確化するためには、そこにどんな脅威や問題があり、それによって何が引き起こされるのかを整理していくことが必要になってきます。
AWSには上記のように様々なセキュリティ対策サービスがありますが、仮にすべてを使ったとしてもセキュリティが万全になった言えるわけではありません。
それぞれのサービスが対象としている解決したいセキュリティ上の課題を理解し、適切にサービスを設定していくことが重要です。
情報セキュリティの目的（CIA）
一般的に情報セキュリティの目的は、Confidentiality（機密性）、Integrity（完全性）、Avilability（可用性）の3つの頭文字をとり、CIAを維持することと言われています。
- Confidentiality（機密性）
- 許可された者だけが情報にアクセスできる
- 攻撃、情報漏洩、盗聴などを防ぐ
- Integrity（完全性）
- 情報が決められた方法のみで変更され、信頼でき、一貫性がある
- 改ざんや不正な変更を防ぐ
- Avilability（可用性）
- 必要な情報にアクセスでき、使用できる
- データ層の破壊やサービス拒否攻撃を防ぐ
これら３つのバランスをとりながら、セキュリティを実現していく必要があります。
ワークロードを安全に運用するには
上記の目的を実現するためのヒントとして本セッションではAWS Well-Architected フレームワークをヒントとして使うことを推奨しています。
AWS Well-Architected フレームワークのセキュリティの柱のベストプラクティスの中に、
• 脅威モデルを使⽤してリスクを特定し、優先順位を付ける:脅威モデルを使⽤して潜在的な脅威を特定し、その登録を最新の状態に維持します。脅威に優先順位を付け、セキュリティコントロールを調整して防⽌、検出、対応を⾏います。進化するセキュリティ環境の状況に応じてセキュリティコントロールを再確認および維持します
というものがあります。ここで出てくる脅威モデルとは何でしょう。
脅威モデリングという考え方は潜在的なセキュリティ問題を特定するための設計時のアクティビティであるといわれています。
開発しているアプリケーションに対してどのような脅威が考えられるかをリストアップし、驚異の影響を考慮したうえで優先順位をつけながら具体的な対応策を考えていきます。
- アセット、アクター、エントリポイント、コンポーネントおよび信頼レベル
- 驚異のリスト
- 脅威ごとの軽減策
- リスクマトリックスの作成、確認
上記のような情報を定義していきます。
脅威モデリングの手法
脅威モデリングの手法として、有名なものにMicrosoftが提唱したSTRIDEというものがあります。これは、
- Spoofing（なりすまし）
- Tampering（改ざん）
- Requdiation（否認）
- Information Disclosure（情報漏洩）
- Denial of Service（サービス拒否）
- Elevation of Privilege（権限昇格）
この6つの頭文字ををとったよくある脅威の特性ごとに整理して脅威を洗い出していく考え方です。
本セッションではセキュリティ驚異のリストや、セキュリティガイドラインなどの紹介もありましたがこちらのレポートでは割愛します。
責任共有モデルと脅威モデリング
AWSではサービスごとに責任の分界点が異なっており大きく上記のように大きく3つにわけることができます。これを理解して脅威モデリングの対象範囲を絞り込むことが可能です。
セキュリティを実装する
Shift-Left
ソフトウェア開発のライフサイクルの早い段階からセキュリティに取り組むという考え方になります。
上記の図は、これまでの手法でセキュリティに取り組んだものとShift-Leftで取り組んだものを比べたイメージ図になります。
これまでの手法（青いグラフ）で設計構築が進みテストの段階からやっとセキュリティを考え始めると、結果としてリリースのころに考慮事項が一番増えてしまっています。これだと考慮漏れなどが発覚し、リリースに影響することもあり得ます。
Shift-Leftモデル（赤いグラフ）の場合、構築の段階で一番大きな山ができています。リリース時にはセキュリティについて考慮することはかなり減っているので、リリースに安心して臨むことができます。
上記の図を見て、開発チームの工数が増えるのでは？と不安に思う方もいらっしゃるかもしれません。
- ソースコードの修正は早期に実装するほどコストが低い
- 専任セキュリティチームに都度依頼する時間や人為的リソースを削減可能。
- 開発チームのセキュリティ意識が高まる
- 多くのプロセスが様々な方法で自動化できる
などの理由から、結果的にメリットの方が大きいといえるでしょう。
セキュリティ対応の自動化
Shift-Leftの話がありましたが、セキュリティは開発段階のすべてのレベルで注入することが可能です。
本セッションでははShift-Leftにのっとってプランからテストまでのフェーズでできることを取り上げていました。
コーディング
- IDEセキュリティプラグイン
- 開発者へ迅速なセキュリティに関するフィードバックを受け取ることが可能
- コーディングの段階から潜在リスクを防止
- 通常、正規表現ベースのアプローチが用いられる
- 他のフェーズ出のアプローチと組み合わせて利用することを推奨
- Pre-Commitフック
- アクセスキー、アクセストークン、SSHキーなどの機密情報は、群発的なgitコミットにより誤って流出の可能性がある
- Pre-Commit フックは、開発者のマシンまたはクラウド IDE にインストールし、機密データをフィルタリングし、機密情報が残ったままではコミットできないようにする
- 通常、正規表現ベースのアプローチが⽤いられる
- コードレビューの実施
- バグを減らすこと自体がセキュリティに効果あり
- 必要に応じたコーディング規約を策定/参照する
- フレームワークを正しく使うことを徹底する。
- Amazon CodeGuru(コードに欠陥がある部分やアプリケーションの実行コストが高い部分を特定し、改善方法含めて推奨してくれるサービス）
- 人のレビューの前にAmazon CodeGuruを挟むことで、簡単な問題を解決したうえでコードレビューを実施
- CodeGuru Secrets Detector（New）を使う
- CodeGuru Secrets Detectorはソースコードだけではなく、設定ファイル(*.yml,*.xml,*cfg etc) にハードコードされたシークレット( AWS,Github,Slack etc) を検出する
- 承認情報や機密情報の保持
- 承認情報やAPIキーはコードに埋め込まずにセキュアに外部へ保持
- AWS System Manager Parameter Storeを使う
- AWS Secrets Managerを使う
ビルド
- 静的アプリケーションセキュリティテスト
- 開発したコードにおけるセキュリティの脆弱性を分析
- SQLインジェクション、XSS、不安全なライブラリなど
- 誤検知の管理は対応が必要
- CodeGuru Secrets Detectorを使う
テスト
- 動的アプリケーションセキュリティテスト
- ツールを使用したブラック/グレーボックスのセキュリティテスト
- デプロイメント固有の問題の特定
- SASTの結果と比較して、誤検出を除外
※特定サービスの侵入テストはAWSの事前承認なく実施可能ですが、禁止されている行為や事前申請が必要なサービスもあるため、ドキュメントやポリシーを予めご確認ください。
CI/CDパイプラインにどのように実装するか
本セッションではCI/CDパイプラインにセキュリティテストを導入していく例としてこのような図が用意されていました。
この図のようにセキュリティテストを実施していくことができます。
まとめ
- 脅威モデリングを考えて、やることを明確化する
- 実装はShift-Left推奨。自動化をうまく使い開発ライフサイクルに組み込んでいく
感想
脅威モデリングの具体的な考え方がとても参考になりました。考え方だけでなくかなり具体例をだして説明がなされていたので、セキュリティ対策に悩む開発者の方にはかなり明確に方向性を示してくれる部分がおすすめのセッションでした！
0
