Slide 1
Slide 1 text
100アカウントを見据えた
AWSマルチアカウント運用
2022年05月19日(木)
弥生株式会社
開発本部 インフラチーム
TechL 峯岸純也
Slide 2
Slide 2 text
突然ですが
弥生のAWSアカウント数は
いくつあるでしょうか？
Slide 3
Slide 3 text
５８です
マルチアカウント環境にする前のAWSアカウントは
「４」個です
Slide 4
Slide 4 text
お話したいこと
AWSを利用するにあたりAWSアカウント構成を考え直してみた
【これまで】各環境ごとのAWSアカウント構成（本番環境、統合環境)
【これから】サービスごとにAWSアカウントを払い出す
AWSアカウントがマルチアカウント環境になった
ガバナンス強化のためにしたこと
インフラチームの役割と課題
Slide 5
Slide 5 text
本日の登場人物
佐々木淳志（ささきあつし）
新サービス全体の
アーキテクチャを考えたり、考えたり etc
峯岸純也（みねぎしじゅんや）
インフラチーム
インフラ面の技術検討・構築 etc
Slide 6
Slide 6 text
自己紹介
弥生株式会社 開発本部 インフラチーム TechL （Technical Leader）
峯岸 純也
2020年1月に弥生にJoin
インフラ経歴ゼロで入社させていただく
弥生インフラ領域の何でも屋さんです
過去のお仕事は、Java / C#メインで開発 etc
プログラミングが嫌いで昔からインフラやりたかった
自宅にCisco Catalyst 1000あります
最近のお仕事内容
AWSインフラ / セキュリティ / ガバナンス周り
既存インフラ環境の運用保守（オンプレ・AWS・Azure）
断捨離大臣、防衛大臣に任命される
趣味
犬、ウィスキーミニボトル集め
アイコンは常に犬
Slide 7
Slide 7 text
これまでのインフラチーム
本番アカウント
統合アカウント
Service A Service B Service C Service D Service E
Service A Service B Service C Service D Service E
インフラチーム
各チーム担当者
IAMユーザ作成・削除
IAMユーザ権限変更
本番 / 検証環境構築・削除
EC2停止・起動
メンテナンス作業
問い合わせ
etc
これが58アカウントに
なったら死人が出る
Slide 8
Slide 8 text
AWSアカウント数が現時点でも14倍に
インフラチームの人数も14倍に・・・
はならないので、これまでと異なる動きをしていかないとダメ
新しいAWS環境は各製品サービスごとに
AWSアカウントを持たせるマルチアカウント
環境にしようと思っていますのでー
それだとインフラ死んじゃいますって
今までと同じく全部をインフラが担った場
合はそうなるよね
AWSはマルチアカウント環境向けに
「ControlTower」っていうサービスがあるん
だ
そのサービスを使って製品サービスチー
ムに渡したアカウントは管理してもらうよう
にしよう
了解です
Slide 9
Slide 9 text
AWSセキュリティの大きな観点３つ
AWS Management
Console
AWS Command Line
Interface (AWS CLI)
Amazon Simple Storage
Service (Amazon S3)
AWS Lambda
Role
VPC
Endpoints
VPN gateway
Internet gateway
subnet
Role
AWS Service Catalog AWS Config
AWS Trusted Advisor AWS Systems Manager AWS CloudTrail
AWS上に構築するシステムのセキュリティ
AWSアカウント自体の管理
(IAMの設計・運用)
セキュリティを維持・管理するための施策
Slide 10
Slide 10 text
ControlTowerの構成
Master Account
Log Archive Account Audit Account User Account
ControlTower
CloudFormation
CloudFormation CloudFormation CloudFormation VPC
SNS
Config
S3
CloudTrail & Config Log
Service Catalog
Single Sign-On
Organizations
インフラ管理
各チーム管理
Slide 11
Slide 11 text
Control Towerを使ってどうなっているか？
Master Account (Control Tower / SSO)
ステージング環境
勉強用アカウント
Audit (各ツール類) / LogArchive (ログ集約)
開発環境
本番環境
Master Accountから見たAWS Organizationsの画面
インフラ管理
各チーム管理
Slide 12
Slide 12 text
Control Towerの嬉しいところ
ガードレール機能
自分で設定するとめんどくさい組織的な共通ルールを簡単に有効化できる
ルートユーザとしてのアクションを許可しない
CloudTrail証跡 / Config自動設定
自動的に有効化
ログをLogArchiveアカウントへ集約
Slide 13
Slide 13 text
Control Towerを使うと
できるよー
でも準備としてCFnでConfigやCloudTrailを
自動的に有効化したり、Organizationsにア
カウント作ったりを自分でやるの大変じゃ
ない？
自分で地道にポチポチやっても出来るし、
ある程度の範囲を自動的にベストプラク
ティスに沿って実行してくれるのが
ControlTowerなんですね
Yes！
インフラチームを14倍の体制にしなくても、
ControlTowerを使ったアカウント追加運用
なら出来そうでしょ？
確かにこれならやれそうです！
ControlTowerを使ってアカウント発行や
管理がしやすくなるのはなんとなくわか
りました
でもOrganizationsやCFnのStackSetsを使
えば同じことできますよね？
Slide 14
Slide 14 text
AWSセキュリティの大きな観点３つ
AWS Management
Console
AWS Command Line
Interface (AWS CLI)
Amazon Simple Storage
Service (Amazon S3)
AWS Lambda
Role
VPC
Endpoints
VPN gateway
Internet gateway
subnet
Role
AWS Service Catalog AWS Config
AWS Trusted Advisor AWS Systems Manager AWS CloudTrail
AWS上に構築するシステムのセキュリティ
AWSアカウント自体の管理
(IAMの設計・運用)
セキュリティを維持・管理するための施策
Slide 15
Slide 15 text
IAMユーザからの脱却
IAMユーザ止めましょう
ControlTowerでSSOサービスとの連携があ
るので、SSOやっちゃいましょうよ
マルチアカウント環境にする前の運用で
はIAMユーザの権限で大変な想いをして
いるのでやるなら今ですね
Azure ADもすでに運用されているようです
し、連携はそこまで大変ではないかと
やっちゃいましょう
了解です
各製品サービスのアカウントで、必要な
人数分IAMユーザ作成していると大変に
なっちゃいますよね
Slide 16
Slide 16 text
AWS Single Sign-On構成図
Organizations
Single Sign-On
Azure AD
プロビジョニング
Master Account
User Account
権限・ユーザの配布
ログイン用IAM
リソース作成不要
各人のIAMユーザ管理からの解放
必要なIAMユーザは各チームへお任せ
実際には
権限が紐づいている
AWSアカウントが表示される
Slide 17
Slide 17 text
デフォルトSSO権限セット問題
どうしたのかな？
AWSAdministratorAccess
AWSPowerUserAccess
AWSReadOnlyAccess
の３つくらいしかありません ふむふむ
これだと細かい権限、例えばあるS3バ
ケットのみに絞るなどの要望がいっぱい
きちゃいます
インフラチームの体制を14倍にｗｗｗ
大変です
SSOを設定したらデフォルトの権限セット
が！！？
それは無理ｗｗｗ
SSOの権限セットは最低限しか用意されて
いない
なので権限を作成できる権限を移譲できる
か検討しよう
Slide 18
Slide 18 text
SSO権限セット作成の委任
Organizations
Master Account
Other SSO User Account
DelegatedOUAdmin
権限セットの一時付与
非常に多数になりがちなIAMポリシー管理からの解放
必要な権限セット作成は各チームへお任せ
役割分担
①各チームからインフラへ「DelegatedOUAdmin」付与依頼
②インフラで必要メンバーへ付与
③付与されたメンバーがSSO権限セットを作成
④作成したSSO権限セットを必要なメンバーへ付与する依頼をインフラへ
⑤インフラで必要メンバーへ作成されたSSO権限セットを付与
Slide 19
Slide 19 text
AWSセキュリティの大きな観点３つ+α
AWS Management
Console
AWS Command Line
Interface (AWS CLI)
Amazon Simple Storage
Service (Amazon S3)
AWS Lambda
Role
VPC
Endpoints
VPN gateway
Internet gateway
subnet
Role
AWS Service Catalog AWS Config
AWS Trusted Advisor AWS Systems Manager AWS CloudTrail
AWS上に構築するシステムのセキュリティ
AWSアカウント自体の管理
(IAMの設計・運用)
セキュリティを維持・管理するための施策
Slide 20
Slide 20 text
その他の自動化
StackSetsとOrganizationsの連携
ControlTowerでアカウント追加時に、CloudFormationのStackSetsを実行
必要なサービスを自動的に有効（+最低限必要の設定を投入）
Master Account
AWS CloudFormation
Stack
AWS CloudTrail
AWS Security Hub
AWS Config
AWS IAM Access
Analyzer
Amazon GuardDuty Amazon Inspector
ControlTower
StackSetsで自動有効化 (設定投入) されるサービス
AWS Compute Optimizer
Amazon Detective
Slide 21
Slide 21 text
GuardDuty検知方法
そうだね
AWS独自基準で過去にアタックを仕掛けて
きている有名なIPアドレスとかを検知してア
ラートにしているからね
既存商用サービスのほうだと、インフラ
チームにメールが送付されるようになっ
ているんですが、メール数が多くて見逃
がしやすいかなと ふむふむ、いい案ある？
EventBridgeとChatbotを使って、Slackに
投稿しちゃうのはどうでしょうか？
GuardDutyで検知したレベルにもよりま
すけど、なるべく早く調査・対応したほう
がいいですよね？
いいんでない？
チームが通常利用しているSlackに投稿さ
れるのは嫌とかありそうだから、どのチャ
ンネルが良いか取りまとめておくね
Slide 22
Slide 22 text
GuardDutyの検知
Audit Account
Amazon GuardDuty Amazon EventBridge AWS Chatbot Slack
GuardDutyの検知 / 対応
各チームに依頼出来る仕組みを提供出来た
メールは1日の受信件数が多くて見逃がしやすいのでSlackへ
全アカウントの検知内容を通知するチャンネル
その他は各チームに合わせたSlackチャンネルへ通知
GuardDutyのテスト投稿
Slide 23
Slide 23 text
AWSからの通知
最終的には物理のマシンで動いているも
のだからね
老朽化したハードウェアに乗っているEC2
インスタンスが運悪く当たったら、メンテナ
ンスが連発しちゃうのかもね
メールだと見逃しやすいんですよね。。
誰かがキャッチすればいいんですけど
メール＋αでの通知にしたいところだね
AWS Helth Awareなるものがあるっぽい
のでこいつ仕込んでみますね
AWSからメールで、「メンテナンスするよ」
とか通知が来るじゃないですか
あれって、来るときはタイミングを図った
ように連発で来るんですよね。。。
Slide 24
Slide 24 text
AWS Health Aware全体構成
Master Account
Amazon EventBridge
Lambda
Health
AWS Secrets Manager Slack
Amazon DynamoDB
User Account
Slide 25
Slide 25 text
AWS Health Awareの効果
AWSからの通知の見落とし予防
メール & Personal Health Dashboardにも連絡は来ているが見落としがち
障害情報をすばやくキャッチ
Service Healthに関する情報も受け取るように設定
以下のリージョンについてHealth関連の通知を受信するように設定
東京リージョン、大阪リージョン、バージニアリージョン、グローバルリージョン
※全リージョンにすると通知が多くなりすぎるため
Slide 26
Slide 26 text
検証用サブドメイン問題
しつこい
すみません
今までDNS関連も全てインフラ管理に
なっていたので・・・
SSO権限セットと同じくDNSも移譲しちゃえ
payroll.yayoi-kk.co.jpのNSレコードをAWS
へ向けて
xxx.payroll.yayoi-kk.co.jp
のxxx部分を各チームにお任せしちゃう
んですね？
大変です
各チームから検証用のサブドメインを、
数十個程度必要という話が来てます
インフラチームの体制を14倍にｗｗｗ
そうそう
DNSの要否だって各チームが一番詳しい
から定期的な棚卸だってできるし
yayoi-kk.co.jpは引き続きインフラ管理だけ
ど、配下は各チーム任せでどうよ
Slide 27
Slide 27 text
サブドメインの委任
ホストゾーン
xxx.yayoi-kk.co.jp作成
nsレコードA
nsレコードB
nsレコードC
nsレコードD
Amazon Route 53
yayoi-kk.co.jp管理DNS
NSレコード登録
nsレコードA
nsレコードB
nsレコードC
nsレコードD
DNSレコード登録
subdomainA.xxx.yayoi-kk.co.jp
subdomainB.xxx.yayoi-kk.co.jp
subdomainA.xxx.yayoi-kk.co.jp
subdomainB.xxx.yayoi-kk.co.jp
インフラは
NSレコードの登録のみで、
後は各チームで必要な分だ
けサブドメインをRoute53か
ら発行してもらえる
Slide 28
Slide 28 text
AWSセキュリティの大きな観点３つ+αパート2
AWS Management
Console
AWS Command Line
Interface (AWS CLI)
Amazon Simple Storage
Service (Amazon S3)
AWS Lambda
Role
VPC
Endpoints
VPN gateway
Internet gateway
subnet
Role
AWS Service Catalog AWS Config
AWS Trusted Advisor AWS Systems Manager AWS CloudTrail
AWS上に構築するシステムのセキュリティ
AWSアカウント自体の管理
(IAMの設計・運用)
セキュリティを維持・管理するための施策
前半パート終了
Slide 29
Slide 29 text
前半戦終わり
Slide 30
Slide 30 text
AWSセキュリティの大きな観点３つ+αパート2
AWS Management
Console
AWS Command Line
Interface (AWS CLI)
Amazon Simple Storage
Service (Amazon S3)
AWS Lambda
Role
VPC
Endpoints
VPN gateway
Internet gateway
subnet
Role
AWS Service Catalog AWS Config
AWS Trusted Advisor AWS Systems Manager AWS CloudTrail
AWS上に構築するシステムのセキュリティ
AWSアカウント自体の管理
(IAMの設計・運用)
セキュリティを維持・管理するための施策
Slide 31
Slide 31 text
何かあったとき問題
何かインシデントが発生した際に
LogArchiveアカウントから該当ログを提供
するとかかな
そうすると各種ログから何があったか？
を確認出来るような仕組みも準備してお
いたほうが良さそうですね
SIEM on Amazon ESっていうのがあるみたい
だよ
SIEM on Amazon ES。。。
調べてみます！
インフラ管理のアカウントが限定的に
なって、定型外の作業が発生するとした
らなんでしょうかね・・・
Slide 32
Slide 32 text
SIEMとは
Security Information and Event Management の略で、セキュリティ機
器、ネットワーク機器、その他のあらゆる機器のデータを収集及び一
元管理をして、相関分析によって脅威検出とインシデントレスポンス
をサポートするためのソリューションです。
Amazon OS は、オープンソースの Opensearchと Kibana を大規模か
つ簡単でコスト効率の良い方法を使用してデプロイ、保護、実行する
完全マネージド型サービスです。
Slide 33
Slide 33 text
SIEM全体構成図
各Account
Amazon Kinesis
Data Firehose
Amazon
OpenSearch Service
Log Archive Account
Delivery Stream
S3 Export
S3 Export Replication
S3
ログ集約用S3
Audit Account
SIEM取込み用S3
Lambda Function
es-loader
Replication
Slide 34
Slide 34 text
ログ取り込み別SIEM VPC Flow log(難易度★)
各Account
Amazon Kinesis
Data Firehose
Amazon
OpenSearch Service
Log Archive Account
Delivery Stream
S3 Export
S3 Export Replication
S3
ログ集約用S3
Audit Account
SIEM取込み用S3
Lambda Function
es-loader
Replication
VPC
Slide 35
Slide 35 text
SIEM VPC Flow logのダッシュボード
Slide 36
Slide 36 text
ログ取り込み別SIEM CloudTrail(難易度★)
各Account
Amazon Kinesis
Data Firehose
Amazon
OpenSearch Service
Log Archive Account
Delivery Stream
S3 Export
S3 Export Replication
S3
ログ集約用S3
Audit Account
SIEM取込み用S3
Lambda Function
es-loader
Replication
ControlTower環境で作成したアカ
ウントであれば、自動的に
LogArchiveアカウントに保存される
ハマりPoint
トリガーにS3が設定されているが、プレフィックスに
組織IDが入っていない
ControlTowerの場合は、組織IDが付与されるので、
トリガーの設定も変更しないとSIEMに取り込まれな
い
Slide 37
Slide 37 text
SIEM CloudTrailのダッシュボード
Slide 38
Slide 38 text
ログ取り込み別SIEM SecurityHub(難易度★★)
各Account
Amazon Kinesis
Data Firehose
Amazon
OpenSearch Service
Log Archive Account
Delivery Stream
S3 Export
S3 Export Replication
S3
ログ集約用S3
Audit Account
SIEM取込み用S3
Lambda Function
es-loader
Replication
ハマりPoint
Kinesis Data Firehoseはマネジメントコンソール上からは、別アカウ
ントのS3は指定できない
AWS CLIから指定する必要がある (※2021年12月現在)
AWS Security Hub
Slide 39
Slide 39 text
SIEM SecurityHubのダッシュボード
Slide 40
Slide 40 text
ログ取り込み別SIEM GuardDuty(難易度★★★)
各Account
Amazon Kinesis
Data Firehose
Amazon
OpenSearch Service
Log Archive Account
Delivery Stream
S3 Export
S3 Export Replication
S3
ログ集約用S3
Audit Account
SIEM取込み用S3
Lambda Function
es-loader
Replication
ハマりPoint
KMSキーのポリシー、S3バケットのポリシー、es-loaderのポリシー
が正しく付与されていないと暗号化 / 複合化が出来ずにSIEM環境に取り込ま
れない
特にS3レプリケーションのステータスは「FAILED」という表記のみで、サポートに
問い合わせしても、クロスアカウントレプリケーションのため、それぞれのアカ
ウントでサポート起票が必要という部分で苦戦した
AWS KMS key AWS KMS key
Amazon GuardDuty
Slide 41
Slide 41 text
SIEM GuardDutyのダッシュボード
Slide 42
Slide 42 text
SIEM環境について
注意点
何かあった時の事象を解消してくれる万能ツールではない
何かあった時にSIEMを検索して、該当の日時に怪しいログがあるとか、ここから調査を
はじめればよいという位置づけ
実際にはLogArchiveアカウントの生ログを見る必要が出てくる可能性もある
その他のログ取り込み
鋭意対応（検証）中
Slide 43
Slide 43 text
AWS利用料
じゃあ、料金確認も各チームに任せられる
ような仕組みを用意しちゃえ
QuickSightで何か出来そうじゃないかな
QuickSightのハンズオンしてもらって、
さっそく作ってみました！
いいね！
色んなグラフのデザインとかあって、ハマる
と沼になりそうだね
画面でポチポチ簡単にグラフィカルな体
裁変更が出来るので、延々とディテール
に凝ってハマってしまいそうです・・・
ほどほどにしましょう
これまでだと、年間のAWS予算とか、都
度どのサービスでどのくらいの料金が掛
かっているか？とか問い合わせが多
かったりします
Slide 44
Slide 44 text
料金確認の全体構成
Master Account Log Archive Account
ログ集約用S3
Audit Account
AWS Cost &
Usage Report S3
Amazon QuickSight
AWS Glue
Amazon Athena
Crawler
IAM IdP
Single Sign-On
Client PC
Single Sign-Onアプリケーション
属性マッピング
Slide 45
Slide 45 text
料金確認の内容
日別の利用料とアカウント数 (週別、月別もあります)
Slide 46
Slide 46 text
料金確認の内容
日別のサービス別利用料 (週別、月別もあります)
Slide 47
Slide 47 text
料金確認の内容
日別のアカウント別利用料 (週別、月別もあります)
Slide 48
Slide 48 text
料金確認の内容
利用料割合 (サービス別 / アカウント別)
Slide 49
Slide 49 text
料金データ (CUR) のイケてないところ
アカウント名がデータにない（アカウントIDを覚えてないといけない）
そこで・・・サーバーレスで自動化してアカウントリストを取得
Master Account Audit Account
S3
Amazon QuickSight
Amazon Athena
Amazon EventBridge AWS CodeBuild
S3
File system
AWS CLIを活用して
AccountId, AccountName
<12桁のアカウント>, アカウント名
<12桁のアカウント>, アカウント名
といったCSVファイルを作成
CUR Table AccountListTable
QuickSightの各グラフでアカウント
名を表示させるために両テーブル
をアカウントIDで結合
ControlTower
Slide 50
Slide 50 text
料金確認の効果
各チームで利用料を気にしてくれるようになった
利用料割合から、「なぜ、こんな高いのか？」
どうすればもっと安くなるか？
これまでインフラチームから利用料を都度提供してきたが、これで都度各チー
ムに確認、改善をしていただけるようなものを提供出来た
今後はAWS予算も各チームで・・・やってもらえるかも？
Slide 51
Slide 51 text
AWSガバナンス
もちのろん
Security HubやInspector、AWS Configな
ど、ある程度のルールに沿った検知
サービスは有効化していますが、是正と
なると、全体的にどれだけ守れているか
とかそういったものを見れた方がいいで
しょうか
だれがやるかの部分は置いておくとして、
どれだけ今守れているか、守れていない
か、などの全体感は見れるようにしておい
て、守れていないルールがどのアカウント
で多いかとか、そういう確認は必要になる
ね
せっかくQuickSightを料金確認ツールとし
て使えるようにしたので、この件も
QuickSightでやりますか
近いうちにマルチアカウント環境のガバ
ナンス強化・是正活動も取り組むことに
なりますよね
Slide 52
Slide 52 text
AWS Configダッシュボードの全体構成
Master Account
Log Archive Account
ログ集約用S3
Audit Account
Amazon QuickSight
Amazon Athena
IAM IdP
Single Sign-On
Client PC
Single Sign-Onアプリケーション
属性マッピング
AWS Config
各Account
Slide 53
Slide 53 text
コンプライアンス全体
Slide 54
Slide 54 text
EC2情報
Slide 55
Slide 55 text
RDS情報
Slide 56
Slide 56 text
IAM情報
Slide 57
Slide 57 text
VPC情報
Slide 58
Slide 58 text
AWS Configダッシュボード化ワンポイント
Master Account Audit Account
Amazon Athena
Amazon EventBridge AWS CodeBuild
ControlTower Amazon EventBridge
AWS Config用のAthenaテーブル更新自動化
アカウントが追加されたり、削除されたりした場合に、アカウントID情報を
Athenaのテーブルプロパティとして連携する必要がある
EventBridgeでアカウント追加、削除のクロスアカウント連携
CodeBuildでAthenaのテーブルを更新するクエリを生成・実行
Slide 59
Slide 59 text
AWS Configダッシュボードの効果
コンプライアンス違反の全体感
今後の是正活動時にコンプライアンス違反が減ってきているかを確認可能
コスト管理
高額なEC2 / RDSインスタンスタイプを使用していないか
リスク管理
不要なIAMユーザ / ロールがないか
などをざっくり確認出来る
Slide 60
Slide 60 text
ここまでの振り返り
Slide 61
Slide 61 text
スケジュール感
21/08 21/09 21/10 21/11 21/12 22/01 22/02 22/03 22/04 22/05 22/06 22/07
ControlTower構築
Single Sign-On設定
SIEM on Amazon ES
GuardDuty検知
AWS Health Aware
料金確認QuickSight
AWS Config QuickSight
Security違反自動検知v1
構成図自動描画
是正活動
別
件
で
忙
し
か
っ
た
Slide 62
Slide 62 text
効果
これまで マルチアカウント環境
AWSアカウント作成 ー 最短30分
IAMユーザ作成 依頼によるが1week程度かかる時も 最短5分
SIEM ー AWS各種ログの調査
GuardDuty メール Slackで関係各所へメンション
AWS Health Aware メール Slackで関係各所へメンション
料金確認QuickSight インフラチームにて予実を確認 各チームでコスト削減対応
AWS Config QuickSight ー 今後の是正活動に活用予定
Security違反自動検知v1 レビューで発見された危ないセキュリ
ティ設定を連絡して対応
自動検知
（場合によっては）自動削除
構成図自動描画 ー 全アカウントの構成図を日次で更新
開発止めないスピーディーを！何かあれば調査を！検知もスピーディーに！
利便性のあるツール類も！是正活動の視覚化！リスクコントロールもするぞ！
結果盛りだくさんに・・・よく一人でやったなと自分を褒めたい（褒めて佐々木さん！ついでにお給料も上げてｗ）
Slide 63
Slide 63 text
インフラチームの新しい役割
AWS100アカウント規模の環境を見据えた運用を考える
2021年8月から2022年5月の10か月でアカウント数「58」、今後も増加が加速
していくと思われる
全てを担わない、けど全てを見て各チームで利用しやすいものを提
案改善していく
各アカウントの管理を各チームにお任せしているが、全てのアカウントの
Admin権限をインフラチームも持っている
何かあれば相談してもらって、実際に環境を見て回答することが可能
誰かからこれをやろうと具体的な指示があるわけでもない、でも誰か
がやらないといずれ大変な目に合う
Slide 64
Slide 64 text
課題
ある程度の検知の仕組みは出来てきた
検知から是正の方法やルールを決めていく必要がある
目指せ定型完全自動化！
自動化への改善余地はまだまだある
定型作業で工数を使わず、非定型に集中していく土台を
構成管理
100アカウントレベルの構成管理
運用属人化
徐々に引継ぎ
妥協しない
ここをがんばらないと自分、
または引き継ぐ人が大変
Slide 65
Slide 65 text
Coming Soon
<是正活動>
AWS Trusted Advisorの内容を
QuickSightダッシュボード化
AWSからの改善提案を見える化 <構成管理>
AWS構成図の最新化・維持管理の自動化
<調査>
膨大な量となるCloudTrailログをAthenaでパーティション化
該当日、イベントがわかれば調査がスピーディーに
AWS Security Hub AWS Lambda
<リスク検知→自動復旧>
フルオープンのセキュリティグループを設定してしまった
場合に自動的に検知→削除
Slide 66
Slide 66 text
識別 防御
アイコンで何のサービスかわかるかな？
検知
調査
自動化
復旧
and SIEM
最後に
Slide 67
Slide 67 text
安全で快適な
マルチアカウント環境を
目指して
Slide 68
Slide 68 text
No content
Slide 69
Slide 69 text
メモ
参考URL
■マルチアカウントのベストプラクティス
https://aws.amazon.com/jp/builders-flash/202007/multi-accounts-best-practice/?awsf.filter-
name=*all
■マルチアカウントのベストプラクティス2
https://aws.amazon.com/jp/builders-flash/202009/multi-accounts-best-practice-2/?awsf.filter-
name=*all
■SIEM on Amazon ES
https://github.com/aws-samples/siem-on-amazon-opensearch-
service/blob/main/README_ja.md
■AWS Config QuickSight
https://aws.amazon.com/jp/blogs/mt/visualizing-aws-config-data-using-amazon-athena-and-
amazon-quicksight/
■AWS Health Aware
https://dev.classmethod.jp/articles/organizations-phd-notifies-aha/