Are you well-architected ?

セキュリティどうしてますか？ 難しいですか？ 白状してもらっていいですか？

AWSのセキュリティ、 ぶっちゃけ何をどこまで やればいいのかわかりません！

『わかるわぁ～』 本セッションの対象者

我々はなぜ AWSのセキュリティを がんばるのか？

セキュリティインシデントはとっても困るから！ 特にこっちは マジ勘弁！

というわけで 本日のお話は

アーキテクチャ設計において 大事なデータをどう守るのか？

左手は添えるだけ！？ AWS Well-Architected Frameworkが教えてくれる 大事なデータの守り方 【Security-JAWS #33】 大竹 孝昌 基本が大事

AWS Well-Architected Frameworkとは？ https://aws.amazon.com/jp/architecture/well-architected https://docs.aws.amazon.com/ja_jp/wellarchitected/latest/framework/welcome.html 本フレームワークに関する認識 ・ベストプラクティス集 ・設計原則 ・6つの柱 - 運用上の優秀性 - セキュリティ - 信頼性 - パフォーマンス効率 - コスト最適化 - サステナビリティ （イメージ）

AWS Well-Architected Frameworkとは？ https://jawsdays2022.jaws-ug.jp/sessions/C15 詳しくはこちら！ ○○の件、 大丈夫か？ あんなやり方 こんなやり方 そんなやり方 ベストプラクティス ベストプラクティス 質問 ベストプラクティス 『ベストプラクティス集』ではない！ 個人的結論：リスク評価の質問集

データを守るベスト・オブ・ベストプラクティスは？ 人をデータから遠ざけるとは？ データの閲覧や操作をスクリプトや ダッシュボードなどを経由することで 間接的なデータアクセスを実現すること ↑ 文面を素直に理解するとこの程度ですが、 解釈を工夫することで汎用性が爆上がり

ベストプラクティスは 解釈次第で化ける （注：俺調べ）

セキュリティどうしてますか？ 難しいですか？ 守ってもらっていいですか？ そろそろ

Amazon VPCの内側 ファイル DBのテーブル/レコード まずは守るデータがどこにあるのか把握 どのサービスがデータを保持するのか？ ⇒データを保持するサービスが守り方を決める Amazon S3 Amazon EFS Amazon FSx Amazon RDS Amazon Aurora Amazon DynamoDB Amazon VPCの外側 （インターネット） （サービスへのアクセス経路によっても守り方は変わる）

Amazon VPCの内側 人をデータから遠ざける① ～経路を絞る～ ⇒データソースへのアクセス経路を限定する Amazon EC2 Amazon S3 Amazon EFS Amazon RDS Amazon DynamoDB インターネット Elastic Load Balancing Elastic Network interface EC2 Instance SG-1 Subnet Security Group RDS instance SG-2 Security Group Subnet SG-3 Security Group Subnet Mount target Amazon EFS こっちの経路 は絞れません VPC内のアクセス経路を限定する3点セット １）まずはセキュリティグループのインバウンドルールで送信元とプロトコルを絞る ２）Network ACLによるトラフィック制御を追加（要件次第） ⇒ セキュリティグループとネットワーク ACL を比較する ３）ルートテーブルによるトラフィック制御を追加（構成次第） ちなみに アーキテクチャ設計

人をデータから遠ざける② ～権限を絞る～ ⇒人やプログラムごとにアクセス可能範囲を定義する 人（プログラム含む） データストア 認証 認可 認証と認可は分けて考える！ 混ぜるな危険！！ 認証と認可の管理方法は サービスごとに異なる 雑に列挙するとこんな感じ？ 【Amazon RDS】 ・認証：IAM、DB側の認証機能 ・認可：DB側の権限管理機能 【Amazon EFS】 ・認証：IAM ・認可：EFSアクセスポイント 【DynamoDB】 ・認証：IAM ・認可：IAM 【Amazon S3】 ・認証：IAM ・認可：IAM、S3バケットポリシー、ACL、SCP --- 【補足１】 認証や認可を自前で実装することも可能。 認可したい粒度次第では自前で実装する必要あり。 （ Amazon Verified Permissionsが便利そう！ ） 【補足２】 バックアップデータも本番データと同じ扱いを！ サービスごとに仕組みが違うので ユーザーガイドで確認しましょう （誰が・どこまで アクセスできる？） アーキテクチャ設計

人をデータから遠ざける③ ～手段を絞る～ ⇒データの閲覧や操作をツール経由に制限する Amazon EC2 Amazon QuickSight Amazon S3 Amazon EFS Amazon RDS Amazon DynamoDB インターネット Amazon VPCの内側 Human >_ script AWS Systems Manager Session Manager HTTPS AWS Management Console AWS Management Consoleは 簡易的なビューアなので要対策 DynamoDBやS3などはコンソー ル上から簡単にデータの閲覧が 可能なので、まずはIAMで権限 を剥奪しておく。アクセス拒否 のポリシー追加でもOK。 次にデータへのアクセスに特化 したIAMロールを作成する。ス イッチロールでアラートが飛ぶ ようになれば尚良し！ ログイン後に 自動起動 ダッシュボードや 自製Webアプリなど （直接的なアクセスを間接的なアクセスに変換） 踏み台 サーバ アーキテクチャ設計

人（プログラム含む） データストア 結局、データには 誰がアクセスするか？ 誰がそのデータにアクセスしているか意識する Amazon RDS Elastic Load Balancing Amazon Cognito AWS WAF Amazon CloudFront Amazon Route 53 Users Amazon EC2 データにアクセスするのは （人でなく）プログラム ちょっと 息抜き >_ script Amazon EC2 AWS Systems Manager Session Managerなど RDS Snapshot AWS Management Console コンソールの操作＝利用者がAPIを直接コールするのと同等 プログラム

人をデータから遠ざけた後① ～痕跡を残す～ ⇒必要なものは全て記録せよ！（誰が・どこに残すのかを意識せよ） データストア プログラム バックアップ 人 生成 Amazon RDS >_ script RDS Snapshot AWS Management Console 人 プログラム （アプリケーションやツールなど） 生成 Amazon EC2 （ログ） データストア側で痕跡を残す アクセスする側で痕跡を残す AWS CloudTrail サービス内で ログを管理 Amazon EBS Amazon CloudWatch Amazon S3 AWSの操作履歴は APIの実行履歴として 全てCloudTrailに残る （要有効化） Amazon EFS 【自製プログラムのログ】 どこに残すかは利用者側で設計する必要が ある。ログの保存先候補は選択肢は複数あ るため、ログの要件（保存、管理、活用） によって選定する。 【マネージドサービスのログ】 ログの仕様（出力先、出力タイミングな ど）はサービスごとに異なる。そのため利 用者の期待する挙動を示すかは事前に確認 しておく必要がある。 アーキテクチャ設計

人をデータから遠ざけた後② ～検知と通知～ ⇒すぐに気付きたいものを選別して、アラートを設定 （自動化などのトリガーにしたいものも選別しておこう） AWS CloudTrail Amazon CloudWatch Amazon S3 Amazon EventBridge Amazon SNS Users AWS Lambda 検知して即時行したいアクションは AWS Lambdaなどに仕込んでおこう （リアルタイム性が重要なもの） アーキテクチャ設計

人をデータから遠ざけた後③ ～定期的なログ確認～ ⇒ログを確認 → 設計や運用の改善を検討＆提案 AWS CloudTrail Amazon CloudWatch Amazon S3 （ここがリスクに気付ける最終防衛ライン！） 『なんとなく確認』は意味が無いので 具体的なチェック観点を事前に用意しましょう。 チェックリストは有効か？ 【メリット】 ・実施有無や結果の確認など視認性が高い ・表形式など、管理しやすいフォーマット 【デメリット】 ・チェック項目を鵜呑みにしがち （チェックの目的や観点を意識しない） ・チェックリストのメンテナンスを怠りがち 良くも悪くも使い手次第！ （極めて当たり前ｗ） （ログ監査とも言う） システム 運用

というわけで 本日のまとめ

アーキテクチャ設計において 大事なデータをどう守るのか？ 再掲

アーキテクチャ設計編 ・必殺 3点絞り！ ① 経路を絞れ！ ② 権限を絞れ！ ③ 手段を絞れ！ ・証跡完全掌握攻め！ やらかした後に調査する際、 必要な情報は集められるか？ 【まとめ】人をデータから遠ざける極意 システム運用編 ・定期的なログ確認 ・設計や運用の改善 ぶっちゃけセキュリティ面倒だし システムなんて動けばいんだよｗ 悪魔の囁きに負けてはダメよ！ セキュリティは100％を目指すのよ！ セキュリティの道に終わりはない※ （しかもコストは青天井！！！） 説明責任が果たせる妥当なラインを見極め、 設計や運用の継続的な改善を心がけること！ （鬼畜な天使さん） （心の声） 心のBGM：負けないで（ZARD） ※Amazon GuardDutyやAWS Security Hubなど、活用すべきサービスや 推しベストプラクティスはまだまだありますが、今回のお話はここまで。 （俺の見解） 実はこっちも すごく大事

Are You Well-Architected ?

終