サーバーレスアプリケーションのためのセキュリティアーキテクチャ

サーバーレスアプリケーションの特徴

• サーバー管理が不要
• 柔軟なスケーリング
• アイドル時のリソース確保不要
• 高可用性

サーバーレスなアプリケーションモデル

• イベントソースからファンクションが起動

最も基本的なAWSサーバーレスアーキテクチャ

• Client - API Gateway - Lambda - DynamoDB

AWS Lambda

• サーバーを気にすることのないアプリケーション開発・実行
• インフラ管理不要/高いコスト効率/自分のコードを実行

Amazon API Gateway

• どんな規模であっても、簡単にAPIの作成、配布、保守、監視、保護
• APIの定義とホスティング/ネットワークトラフィック管理/AWSの認証の仕組みを活用

Amazon Cognito User Pools

• ウェブ/モバイルアプリケーションの認証、許可、ユーザー管理をサポート
• ユーザー管理を簡単に/マネージド型ユーザーディレクトリ/拡張されたセキュリティ機能

サーバーレスアプリケーションのユースケース

• Web Applications

  • Static websites
  • Complex web apps
  • Packages for Flask and Express

• Backends

  • Apps & services
  • Mobile
  • IoT
• Data Processing
• Chatbots
• Amazon Alexa
• Autonomous IT

サーバーレスアプリケーションを構成する要素

• ユーザー管理とアイデンティティ

  • Amazon Cognito

• エッジ

  • Amazon CloudFront

• メッセージング/ストリーミング

  • Amazon SNS
  • Amazon Kinesis

• コンピュート

  • Amazon API Gateway
  • AWS Lambda
  • AWS Step Functions

• データ

  • Amazon DynamoDB
  • Amazon S3
  • Amazon Elasticsearch Service

• システム監視とデプロイ

  • Amazon CloudWatch
  • AWS X-Ray

Well-Architected Framework Serverless Application Lens

• クラウドにおけるシステム設計・運用のベストプラクティス集
• ワークロード固有の考え方やベストプラクティスにフォーカスした資料
• https://d1.awsstatic.com/whitepapers/architecture/AWS-Serverless-Applications-Lens.pdf

• セキュリティの柱

  • IDとアクセス管理
  • 発見的統制
  • インフラストラクチャー保護
  • データ保護
  • インシデントレスポンス

IDとアクセス管理の考慮事項

• 考慮事項例

  • APIアクセスの認証認可をどのようにしていますか？
  • LambdaファンクションがアクセスできるAWSサービスをどのように保護していますか？

• 考え方例

  • ユーザー管理とアイデンティティ管理
  • IAMの活用
  • 既存IdPの活用
  • 最小権限の原則

API Gatewayのアクセス認可の方法

• Cognito User Pools Authorizer

  • クライアントがCognito User Poolsに認証をリクエスト
  • Cognito User PoolsがJWT Tokenを返す
  • API GatewayでこのJWT Tokenを検証
  • 検証がパスすればLambda関数を起動

• AWS IAM Authorization

  • クライアントがCognito User Poolsに認証をリクエスト
  • Cognito User PoolsがJWT Tokenを返す
  • クライアントがCognito Identity PoolsにAWSクレデンシャルをリクエスト
  • Cognito Identity Poolsが一時的なクレデンシャルを返す
  • API GatewayがIAMにポリシー検証
  • 検証がパスすればLambda関数を起動

• Lambda Authorizer

  • クライアントがIDプロバイダーに認証をリクエスト
  • IDプロバイダーがカスタムIdPトークンを返す
  • API GatewayがLambdaの中でIDプロバイダーにトークンを検証
  • Lambdaオーソライザーの中でIAMポリシーを生成
  • 処理実行用のLambda関数を起動

発見的統制の考慮事項

• 考慮事項例

  • サーバーレスアプリケーションのログをどのように分析していますか？
  • アプリケーションの依存関係や脆弱性をどのように監視していますか？

• 考え方例

  • アプリケーションログは、CloudWatch Logsの利用
  • AWSサービスAPIの呼び出しは、CloudTrailの利用
  • ログに機微な情報

API Gatewayアクセスログの設定

• 「ログ/トレース」の「カスタムアクセスログ記録」の項目で設定
• ログに記録して良い情報か慎重に判断する
• 機密情報を残すべきでない要件もある

インフラストラクチャー保護の考慮事項

• 考慮事項例

  • LambdaファンクションがアクセスできるVPC内のAWSリソースに関して、どのようにネットワーク境界を保護していますか？

• 考え方例

  • Network ACLやSecurity Groupなどによるネットワーク境界保護

Firewallによるネットワーク境界保護

• API GatewayにAWS WAFを組み合わせる

• AWS WAFルールに基づいた保護

  • Rate Limit
  • 正規表現

データ保護の考慮事項

• サーバーレスアプリケーション内の機微な情報をどのように保護していますか？
• どのように入力値チェックをしますか？

• 考え方例

  • 通信データの暗号化
  • クライアントサイド暗号化
  • ログに機微な情報が含まれる可能性の配慮
  • JSONスキーマやURIパラメータ、クエリ文字列、ヘッダー妥当性検証
  • アプリケーションレベルの入力値検証

保護すべきデータの外部化

• AWS Systems Manager Parameter Store

• AWS Secrets Manager

  • DB認証情報をこちらに格納
  • IAMロールで読み取れる対象を制限

インシデントレスポンスの考慮事項

• （セミナー時間の関係でスキップ）

AWS WAFセキュリティオートメーション

• AWS WAFのフルログをAmazon Kinesis Data Firehoseを経由してS3バケットにPut
• Amazon AthenaでS3上のログを分析
• 分析結果に基づいてAWS WAFルールをアップデート

セキュアな設計のための考慮事項まとめ

1. APIアクセスの認証認可をどのようにしていますか？
2. LambdaファンクションがアクセスできるAWSサービスをどのように保護していますか？
3. サーバーレスアプリケーションのログをどのように分析していますか？
4. アプリケーションの依存関係や脆弱性をどのように監視していますか？
5. LambdaファンクションがアクセスできるVPC内のAWSリソースに関して、どのようにネットワーク境界を保護していますか？
6. サーバーレスアプリケーション内の機微な情報をどのように保護していますか？
7. どのように入力値チェックをしますか？
8. セキュリティインシデントについて調査や対応ができるようにどのような準備をしていますか？

クラウド運用管理の最前線 〜日米の最新状況から〜

日本の企業からの相談事例

• 事業部門：デジタルトランスファー（DX）施策
• 情報システム部門：システム移行
• ガバナンスとセキュリティの確保、閉域網による接続
• クラウドの理解、エンジニアの育成

クラウド活用のフェーズ

• プロジェクト（PROJECT）

• 基盤（FOUDATION）

  • 多くの日本企業はこのあたりのフェーズ

• 移行（MIGRATION）

  • 多くの米国企業はこのあたりのフェーズ
• 変革（REINVENTION）

AWSは「ITのツールボックス」

• 165くらいのサービス
• 単なるインフラサービスではない！

マネジメントコンソールはみんなのもの

• アプリ担当もインフラ担当も操作する

• 仮想サーバ管理ツールと同じ役割分担では運用が非効率

  • RDSのPerformance Insights
  • Lambdaへのデプロイ

ITシステム開発の体制とスケジュール（クラウド活用）

• アカウントを丸ごと払い出す
• 基本設定のテンプレート化
• アカウントを監視
• 既存の運用・監視も活用
• チームのコミュニケーションを減らす

クラウドを活かす運用体制

• アプリ開発&インフラ構築チームは1チームとして構成
• 共通運用チームはアカウントの払い出しとガバナンス

AWSアカウントが提供するもの

• 請求の分離
• セキュリティおよびリソースの境界
• APIの制限およびスロットリング

マルチアカウント管理のゴール

• 監査可能
• スケーラブル
• フレキシブル
• 自動化
• ブロッカーではなくガードレール
• セルフサービス

マルチアカウントのベストプラクティス

• 共通運用チームの管理するアカウント

  • 請求アカウント
  • 請求集約
  • アカウント払い出し
  • 共有サービスアカウント
  • 共有サービス（AD等）
  • 共用ネットワーク
  • セキュリティ&監査アカウント
  • ログの集約
  • 監査の実施

マルチアカウント（4アカウント）によるクラウド運用体制の実装

• 請求

  • 請求と使用量の把握

• セキュリティ&監査

  • セキュリティとコンプライアンス関連のロギングと監査

• 共有サービス

  • ワークロードやアプリケーションの間で共有可能な共通のサービス

• アプリケーション

  • 個別のワークロード、アプリケーションもしくは環境

大規模クラウド運用におけるポイント

• コントロール
• コスト最適化
• 次世代のクラウドマネージメント

ガードレールの設置

• AWS Trusted Adviser
• AWS CloudTrail
• AWS CloudFormation
• Amazon CloudWatch
• AWS Config
• AWS Systems Manager
• AWS Service Catalog
• AWS Marketplace

Amazon CloudFormation

• テンプレート検証

  • cfn-lint
  • cfn-nag

コントロールのポイント

• ガードレールの設計に加え、より早期段階でのポテンシャルリスクへのアプローチが大規模運用には不可欠
• そうすることで、デプロイ後のアラート数をなるべく抑え運用をスケールさせる

• 意図的にコントロール、ガバナンスを効かせる仕組みづくりが必要

  • Ops/Secチームから開発チームへの積極的なフィードバック（DevSecOps）

リフト&シフト最適化のポイント

• ライトサイジング
• 伸縮性向上
• RI/Spot最適化

AWS Trusted Adviser

EC2 Right Sizing

• デプロイして、2週間分のログを入れると最適なサイズのインスタンスを提供してくれる

コスト最適化のポイント

• 規模に応じたツール、サービスの選択
• リコメンデーション機能を前提としたツールの選択
• マルチリージョン、マルチアカウント環境全体

Machine Learning Enabled - 機械学習の活用

• キャパシティプランニング

  • Autoscaling
  • Tired Storage - Intelligent-Tiering

• 異常検知

  • Amazon Kinesis Data Analytics
  • RANDOM_CUT_FOREST

• ノイズキャンセリング

  • Amazon CloudWatch Math Expression

障害に備えるメカニズム

• Resiliency

  • 回復力、回復機能

• Error Ingestion

  • 障害発生時にシステムが想定通りに振る舞うことを確認するために、継続的かつ意図的に障害を引き起こす

Chaos Engineering

• カオスエンジニアリングは、分散システムにおいてシステムが不安定な状態に耐えることのできる環境を構築するための検証のプラクティス
• AWS Gameday

クラウドネイティブなモダンアプリケーション開発を始めよう！クラウドネイティブ設計とデプロイメントパターン

急速なイノベーションはもはや必須

• 今ある人材を活用 = 利益を伸ばす
• 新たな機会を探索 = 新しいアイデアを探求

Innovation Flywheel

• 実験/傾聴/反復

モダンアプリケーション開発

• 素早いアプリケーション開発によって競争的価値を生み出す

モダンアプリケーションの能力・特徴

• Secure
• Resilient
• Elastic
• Modular
• Automated
• Interoperable

アプリケーションのライフサイクル全体にわたってコンプライアンスとセキュリティを構築する

• ライフサイクルをセキュアにすることでイノベーションの速度を落とすことなく脅威に対応

• Authenticate

  • 強力なアクセス制御で認証されていないアクセスを防ぐ
• Authorize
• Audit&Govern
• Validate

アプリケーションの構造をマイクロサービスの集まりにする

• 変更の影響は小さくなると、リリースの速度向上可能に
• Monolith：全てを実行
• Microservices：ひとつのことを実行
• APIと疎結合なコミュニケーションが自動化を可能にして信頼性を向上
• ワークフローで複数のサービスを連携することで、敏捷性、生産性、柔軟性が向上

可能な限りサーバーレスの技術で構築する

• 自動化と抽象化によって課題から解放

  • インフラストラクチャのプロビジョニングや管理が不要
  • 利用単位ごとにオートスケール
  • 価値に対して支払う課金モデル
  • 高い可用性と耐久性

• サーバーレスアーキテクチャは最小の努力で最大のアジリティを提供

  • Focus on business value

• コンピュートの選択はトランスフォーメーションの核心

  • AWS Lambda
  • AWS Fargate

アプリケーションのモデリングとインフラにコードを利用する

• 全てをソフトウェアとして扱うことでインフラのデプロイのスピードとアジリティを向上

• AWS Cloud Development Kit（CDK）

  • もうすぐGA！
  • アプリケーションコードでバックエンドのスタックを作れる
  • 抽象度の高い書き方をすることができる

CI/CDを利用して高品質な機能を迅速にリリースする

• CI/CDを自動化しているチームはコードをより速く、自信を持って書いている

  • 30x 頻繁なデプロイ
  • 440x リードタイムの短縮
  • 60x ミスが減少
  • -21% 予期しない作業の削減

• AWS Developer Tools for CI/CD

  • CodePipeline
  • CodeCommit
  • CodeDeploy

モニタリングによってアプリケーションの振る舞いの洞察を得る

• より速く問題を識別すると、より速く解決できる

• 分散されたアプリケーションをどのように可視化すべきか？

  • Amazon CloudWatch
  • AWS X-Ray

APIゲートウェイパターン

• 複数種類のクライアントとバックエンドの間にAPI Gatewayを挟む

• API Gatewayは以下の機能を簡単に実現できる

  • スロットリング
  • 認証認可
  • キャッシング
  • カスタム認証
  • ドキュメンテーション
  • ステージングの管理
  • WebSocketの対応

サービスディスカバリ/サービスレジストリパターン

• サービス起動時に自分の情報をサービスレジストリに登録する

• AWS Cloud Map

  • DNSベースの解決
  • ARNでの解決もできる

サーキットブレーカーパターン

• サービス間にプロキシ的なシステムを入れる
• 後続のサービスがエラーを何回か返す場合、前段のサービスにすぐレスポンスを返すような動作が可能

• コンテナのサイドカー

  • ECS：Linkerd
  • EKS：Istio + Envoy

コマンドクエリ責務分離パターン

• AWS DynamoDB Streams
• AWS Lambda

イベントソーシングパターン

• 一つのイベントによってそれぞれのデータソースを変更できる
• Amazon Kinesis
• AWS Lambda

コレオグラフィパターン

• Amazon Simple Notification Service
• Amazon Simple Queue Service
• AWS Lambda

集約ログパターン

• Amazon CloudWatch Logs
• AWS X-Ray

Polyglotパーシステンスパターン

• Polyglotパーシステンス

  • 異なるデータ処理のニーズに対しては異なるデータストアを利用する

継続的インテグレーション/デリバリー/デプロイメント

• SPAのCI/CDにはAWS Amplify Consoleを活用可能

  • CodeCommitへのプッシュをトリガーにパイプラインが実行
  • フロントエンドとバックエンドをそれぞれビルドしてデプロイ

• コンテナへのデプロイはCodePipelineを活用可能

  • CodeCommitへのプッシュをトリガーにパイプラインが実行
  • CodeBuild内でDockerfileをビルドしてECRへプッシュ
  • CodePipelineで最新のイメージをECSにデプロイ
  • CodeDeployを使うとECSに対してBlue-Greenデプロイも可能

• AWS Lambdaへのカナリアデプロイ

  • CodeCommitへのプッシュをトリガーにパイプラインが実行
  • AWS CodeDeployでLambdaに対してカナリアデプロイを実施

なぜAWSでモダンアプリケーション開発を行うのか？

• AWSはイノベーターに対してイノベーションや失敗に対する恐れから解放します

感想

re:Cap 2日目で、昨日よりも上手にメモできるようになった気がする。

サーバーレスのセッションでは、Cognito User PoolsでJWT Tokenを発行して、それをAPI Gatewayで検証する方法と、Cognito Identity PoolsでIAMのCredentialsを発行して、それを使ってIAMポリシーでの認可を行う方法を改めて整理することができた。

このあたりが明確になっていなかったから、昔「AWS AppSyncの認証モードをCognito User Poolsにしたときに未認証でアクセスできなくて困っています」なんて質問をしてしまっていたのだと思う。

サーバーレスのセキュリティに関してはまだ全然検討できていなくて、AppSyncのエンドポイントに不正なリクエストが大量に来たらどうするかなど考えてもいなかった。

API Gatewayの場合はAWS WAFを連携してスロットリングやブロックができるとのことだったので、AppSyncではどのようにやるのか、そもそも必要なのかを今後調査して適宜取り入れていきたい。

モダンアプリケーション/マイクロサービスのあたりの話では、昨日のDay1でのサービスメッシュの話にも共通する内容だったので理解しやすかった。

各サービスはシンプルに保って、その間の通信を担当するサービスを組み合わせよう、という考え方がより深まった気がする。

サーバーレスでのバックエンド開発においては、各マネージドサービス間の通信をAWS X-Rayで可視化することでボトルネックを見つけられるようになるとのことなので、そこからモニタリングとパフォーマンスチューニングを始めてみようと思う。