[re:Invent2023 ざっくre:Cap]Improving security through modern application development

# はじめに
みなさんこんばんは！hiropyです。
今回はre:inventで参加したセッションを、英語できないマンなりにざっくり振り返っていこうと思います！

本記事では「Improving security through modern application developmente」について記載していきます。

翻訳ミス、意図の取り違えがあるかもしれませんが、「こんなことしてたんだ」くらいでご参考にしていただけると幸いです。

# セッション概要
- セッション名：SEC227 | Improving security through modern application development
- セッションタイプ：Breakout session
- レベル：200

セッション概要は以下の通りです。

> このセッションでは、最新のアプリケーション開発で使用されるセキュリティ手法と、それらがレガシーアプリケーションで見られる一般的なセキュリティ課題にどのように対処するのかを探ります。開発ライフサイクルの初期段階におけるセキュリティの統合、コンテナ化アプリケーションやサーバーレスアプリケーションにおける全レイヤーでのセキュリティの適用、APIセキュリティの強化、セキュアコーディングプラクティスの実装などのパターンを学びます。これらのプラクティスを取り入れることで、モダンなアプリケーション開発は、ソフトウェアのデリバリーを加速し、セキュリティ体制を強化することができます。

レガシーアプリケーションで発生していたセキュリティの問題と、モダンアプリケーションだとどう解決できるか、どう変わるかについてのお話です。


# セッション内容
## リリースサイクルとアプリケーションのセキュリティ
レガシーなシステムでは、手動でのデプロイがかなり一般的だった。
ビルドやテストの実行も手動で行っていた。
手動での実施は、手動承認が必要であったり、作業が遅かったりした。

これをセキュリティの観点から見ると、潜在的なセキュリティの問題を見つけるために力を注ぐ必要があり、開発のスピードを低下させた。

開発スピードの低下はセキュリティ問題の修復も遅らせるため、システムに不安の残る状況が続いてしまう。

対するモダンアプリケーションでは、CI/CDパイプラインにより、継続的なインテグレーションや継続的なデプロイを実施できる。
自動化されているので、たくさん改良することができる。

アプリケーションのリリースは自動化したほうがいい。
自動化を強制することで、デリバリの速度を向上させるだけでなく、ヒューマンエラーやミスをなくすこともできる。


## セキュリティ診断
レガシーな開発手法の場合、セキュリティ診断は大抵デプロイの前、フローの遅いタイミングで実施される。
しかし、このやり方でセキュリティに問題点が見つかってしまうと、開発の段階から修正することになり、開発の大きな摩擦、手戻りになってしまう。

このやり方は、セキュリティ問題が発生したら慌てて直すという文化を醸成してしまう。

モダンアプリケーションの開発では、このセキュリティチェックをシフトレフトする。
コードを書く段階からセキュリティ診断を行うことで、最後まで待つよりも早い段階でセキュリティの問題を検知できる。

セキュリティチェックのタイミングが遅れれば遅れるほど、ソフトウェア開発にかかる負担は大きくなる。


## 脅威モデリング
各チームのセキュリティ対策は、脅威モデリングから始まる。
これを実施することで、各チームに最適、かつ一元化されたセキュリティを提供することができる。

脅威モデリングは、まずアプリケーションそのものの設計から始まり、そのアプリケーションに対して、どのような問題が発生しうるかを調査するところからはじまる。
そして、適切なソリューションを設計する。

脅威モデリングに慣れていない場合は、[threat-composer](https://github.com/awslabs/threat-composer) というツールが有効。
脅威モデリングを簡単、シンプルかつ迅速に行うことができる。

## 具体的なセキュリティ対策
- Code Whisperer と CodeGuru Securityの統合によりコードのセキュリティチェックが可能
    - https://aws.amazon.com/jp/blogs/devops/tag/static-code-analysis/
- リポジトリ全体のスキャン
    - 誤ってアップされたアクセスキーやパスワードの検知
- AI/MLを活用した脆弱性の検出、誤検知の軽減
- Codepipelineの活用やGithub, GitLabとの統合
- Amazon Inspector
    - LambdaやECRのスキャンを実施する
- [CloudFormation Guard](https://docs.aws.amazon.com/cfn-guard/latest/ug/what-is-guard.html)
    - テンプレートデプロイ時のルールを定義できる
- [CDK-NAG](https://aws.amazon.com/jp/blogs/news/manage-application-security-and-compliance-with-the-aws-cloud-development-kit-and-cdk-nag/)
    - CDKのセキュリティチェックツール
- [cdk-validator-cfngural](https://github.com/cdklabs/cdk-validator-cfnguard)
    - CDKのバリデーションツール
- IAM Access Analyzer
    - IAM Policyを自動的に追跡し、リスクのあるポリシーを警告する
- CloudFormation ドリフト検出
    - インフラをコード化することで、開発の一貫性を実現できるだけでなく、セキュリティ問題の早期発見や安全性確保にもつながる。


## 現在のアプリケーションとインフラのセキュリティ
従来のアプリケーションは、何人もの人の手により、大規模で複雑になっていることが多い。
対する現在のモダンアプリケーションは、機能ごとに細かくコンポーネントを分けることに重きを置いている。
こうすることで、各機能の拡張が容易になる。
分離することで、システムが完全に停止することを防ぐ効果もある。

レガシーなアプリケーションはその規模や複雑性から過重な権限を与えてしまうことが多かったが、マイクロサービスにすることで権限の分散が可能。なるべく最小限の権限にとどめる。

 マイクロサービスは多層防御を実現できる。

認証はCognito,または外部のIdPで実施できる
これらとAPI Gatewayを組み合わせて、エンドポイントを保護することができる。
特に背後にLambda がある場合は、[Lambda Authorizer](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-use-lambda-authorizer.html)を使用することができる。
API Gatewayに備わった[バリデーション機能](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-method-request-validation.html)もセキュリティ対策になる。


DDos 攻撃に対する１つの対策として、全てのリクエストをCloudFrareを経由させるという選択肢がある。
他にも、Shield advancedやWAFの有効化なども考えられる。

DBのセキュリティについて考慮する点は、クレデンシャル情報の管理。
Secret Manager を使用して保管することが望ましい。
理由は、シンプルにセキュリティ対策ができること、SDKからも操作できること、認証情報の自動ローテーションが可能なこと。

RDSではIAMによる認証も利用することができる。


# さいごに
いかがでしたでしょうか？
皆様のご参考になれば幸いです。