AWS Well-Architected Security とベストプラクティス

© 2021, Amazon Web Services, Inc. or its affiliates. All rights reserved.
アマゾンウェブサービスジャパン株式会社
Partner Solutions Architect 大場崇令
2021/06/03
AWS Well-Architected Security と
ベストプラクティスのご紹介

© 2020, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Amazon Confidential and Trademark
本セッションの対象者とゴール
• クラウドのセキュリティに悩まれている方
• AWS Well-Architected Framework の概要を理解されている方
対象者
ゴール
• セキュリティにおける AWS Well-Architected
フレームワークの活用方法を理解する

Who am I ?
 大場崇令（オオバタカノリ）
 Partner Solutions Architect
@Amazon Web Services Japan K.K.
(Joined 2015/12)
 Background
 AWS テクニカルトレーナー@AWSJ K.K.
 Web サービスのインフラエンジニア
 国内クラウドベンダーにてテクニカルサポート
 好きな AWS サービス
 AWS Well-Architected Tool
 AWS Systems Manager
 AWS Service Catalog
@takaohba
Well-Architected Lead

よくあるクラウド導入の課題と不安
オンプレミスでの経験は豊富だが、
クラウド最適化のための
設計・運用のノウハウが無い…
基本的にオンプレミスの経験や知識が
活用できますので、ご安心ください
＋αとして、よりクラウド効率的に
使うためのノウハウもまとまっています

https://aws.amazon.com/well-architected/
AWS Well-Architected フレームワーク

AWSWell-Architectedフレームワーク(W-A)とは?
・AWS のソリューションアーキテクト (SA)、
パートナー様、お客様の 10 年以上にわたる
経験から作り上げたもの
・AWS とお客様と共に、
W-A も常に進化し続ける
システム設計・運用の”大局的な”考え方と
ベストプラクティス集
End User APN
Partner
SA
https://docs.aws.amazon.com/ja_jp/wellarchitected/latest/framework/welcome.html

Why AWS
Well-Architected
フレームワーク?
AWS のベストプラクティスを学ぶ
ビルドとデプロイを高速化
リスクを緩和または軽減
データドリブンで決定

AWS Well-Architected フレームワークとは？
設計原則
(Design principles)
質問
柱

AWS Well-Architected フレームワークの 5 本の柱
セキュリティ信頼性
パフォーマンス
効率
コスト最適化
運用の優秀性

設計原則 (Design principles)
一般的な設計原則柱固有の設計原則
セキュリティイベントへの備え：
インシデント対応シミュレーションを実⾏し、⾃動化されたツールを
使⽤して、検出、調査、復旧のスピードを上げる

W-A における設計原則
(Design Principles)
必要キャパシティーの推測が不要に
本稼働スケールでシステムをテストする
⾃動化によってアーキテクチャでの実験を容易にする
発展的なアーキテクチャが可能に
データに基づいてアーキテクチャを進化させる
ゲームデーを利⽤して改善する

各柱における設計原則
(Design Principles)
運用の優秀性の柱
• 運用をコードとして実行する
• ⼩規模かつ可逆的な変更を頻繁に⾏う
• 運用手順を定期的に改善する
• 障害を予想する
• 運用上のすべての障害から学ぶ
セキュリティの柱
• 強力なアイデンティティ基盤の実装
• トレーサビリティの実現
• 全レイヤーでセキュリティを適用する
• セキュリティの
ベストプラクティスを自動化する
• 伝送中および保管中のデータの保護
• データに人の手を入れない
• セキュリティイベントに備える
信頼性の柱
• 障害から自動的に復旧する
• 復旧手順をテストする
• ⽔平⽅向にスケールして
ワークロード全体の可⽤性を⾼める
• キャパシティを推測することをやめる
• オートメーションで変更を管理する
パフォーマンス効率の柱
• 最新テクノロジーの標準化
• わずか数分でグローバル展開する
• サーバーレスアーキテクチャを使用する
• より頻繁に実験する
• システムに対する精通の程度を考慮する
コスト最適化の柱
• クラウド財務管理の実装
• 消費モデルを導入する
• 全体的な効率を測定する
• 差別化につながらない高負荷な作業に
費用をかけるのをやめる
• 費用を分析および属性化する

セキュリティの柱における
設計原則
強力なアイデンティティ基盤を実装する
トレーサビリティの実現
全レイヤーでセキュリティを適用する
セキュリティのベストプラクティスを自動化する
伝送中および保管中のデータを保護する
データに人の手を入れない
セキュリティイベントに備える

柱の分野
質問文
質問のコンテキスト
ベストプラクティス
質問と回答形式でのベストプラクティス(例)
インフラストラクチャ保護
Sec6 コンピューティングリソースをどのように保護していますか?
• 脆弱性管理を実行する
• 攻撃領域を削減する
• マネージドサービスを活用する
• コンピューティング保護を自動化する
• ユーザーが遠距離でアクションを実行できるようにする
• ソフトウェアの整合性を検証する
ワークロード内のコンピューティングリソースを内外の脅威から守るには、
複数の防御レイヤーを設ける必要があります。コンピューティングリソース
には、EC2 インスタンス、コンテナ、AWS Lambda 関数、データベース
サービス、IoT デバイスなどがあります。

セキュリティの柱における 10 の質問
SEC 2. ユーザー ID とマシン ID は
どのように管理したらよいでしょうか?
SEC 1. ワークロードを安全に
運用するには、どうすればよいですか?
SEC 4. セキュリティイベントを
どのように検出し、調査していますか？
SEC 3. 人とマシンのアクセス許可は
どのように管理すればよいでしょうか?
SEC 5. ネットワークリソースを
どのように保護しますか?
SEC 6. コンピューティングリソースを
どのように保護していますか?
SEC 7. どのように
データを分類していますか?
SEC 8. 保管時のデータを
SEC 9. 転送時のデータを
SEC 10. インシデントの予測、
対応、復旧はどのように行いますか?

例：セキュリティの質問(抜粋)
[SEC2] ユーザー ID とマシン ID はどのように管理したらよいで
しょうか?
 強力なサインインメカニズムを使用する
 一時的な認証情報を使用する
 シークレットを安全に保存して使用する
 一元化された ID プロバイダーを利用する
 定期的に認証情報を監査およびローテーションする
 ユーザーグループと属性を活用する

しょうか?
 強力なサインインメカニズムを使用する
 一時的な認証情報を使用する
 シークレットを安全に保存して使用する
 一元化された ID プロバイダーを利用する
 定期的に認証情報を監査およびローテーションする
 ユーザーグループと属性を活用する

しょうか?
全項目ベストプラクティスに
則っていないとダメなのか？

しょうか?
全項目ベストプラクティスに
則っていないとダメなのか？
ベストプラクティスを知った上で、
皆様が「(ビジネス的な)判断をする」ための手法
→リスクや改善点の”顕在化”

しょうか?
たとえば EC2 インスタンスにアクセスキーを組み込んでいると…
・長期的なアクセスキーが組み込まれることで、他のリソースに対する不正操作のリスクが増大する
・定期的なキーローテーションを検討する必要がある
複数の AWS アカウントを運用しており、すべての AWS アカウントのアクセスに IAM ユーザーを使用していると…
・扱うクレデンシャルが増えることで、同時にクレデンシャルの漏洩リスクが増える
・異動、退職者が出た場合、どうする？

AWS

Well-Architected レビューの意図
話し合いであり、重⼤な
問題や改善可能な領域の
特定が目的
監査ではない
定期的な見直し
(KAIZEN)
1 回限りの
チェックではない
ワークロードの理解と
適切な改善を検討
適切な関係者で
ディスカッションする

1 回限りのチェックではない
• 設計前の段階でホワイトペーパーを読む
• 質問は必ず読んでおく
• 定期的な見直し (KAIZEN)
• 設計段階 (もしくはその前の段階)
• リリース前
• 運用フェーズ
Throughout
lifecycle
Not a one-time check

https://aws.amazon.com/well-architected-tool/

運用中ワークロードへのW-Aレビュー
ベストプラクティスを理解した上で、判断する
(前準備)
セルフチェック W-Aレビュー実施クラウド最適化
W-Aの質問に答えながら、
設計中の構成や既に運用し
ているシステムの現状確認
(棚卸し)を実施
SAとベストプラクティスとの
ギャップを把握。様々なリス
クやクラウドに最適化できる
ポイントを把握する
ビジネス的な判断や優先度
づけを実施し、よりクラウ
ドに最適化していく
2~3時間の集中的な打ち合わせその後、再度レビュー実施して状況確認
AWS Well-Architected Tools へ入力
Your team
TECHNICAL &
BUSINESS LEADS
APN
Partner
Your team
TECHNICAL &
BUSINESS LEADS
APN
Partner
Your team
TECHNICAL &
BUSINESS LEADS
APN
Partner

運用開始後も
定期的な見直し
(KAIZEN)が重要

運用中ワークロードへのW-Aレビュー
(前準備)
セルフチェック W-Aレビュー実施
W-Aの質問に答えながら、
設計中の構成や既に運用し
ているシステムの現状確認
(棚卸し)を実施
SAとベストプラクティスとの
ギャップを把握。様々なリス
クやクラウドに最適化できる
ポイントを把握する
2~3時間の集中的な打ち合わせ
AWS Well-Architected Tools へ入力
Your team
TECHNICAL &
BUSINESS LEADS
APN
Partner
Your team
TECHNICAL &
BUSINESS LEADS
APN
Partner
次のワークロードに
活かす
既存ワークロードの改善が
できない場合も、次期シス
テムの設計時に活かすこと
が出来る
Your team
TECHNICAL &
BUSINESS LEADS
APN
Partner
事情により既存ワークロードの改善ができない場合…

AWS solutions
architect
AWS
APN partner
AWS
WA tool
Your team technical
and business leads
Self-service
Partner
AWS SA
Well-Architected レビューの選択肢

Well-Architected Partner Program
Well-Architected パートナープログラム発表 (re:Invent2018)
AWS re:Invent 2018 - Keynote with Werner Vogels AWS re:Invent 2018 - Global Partner Keynote

Well-Architected Partners
https://aws.amazon.com/architecture/well-architected/partners/

日本のWell-Architectedパートナー
(※2021 年 06 月現在)

セキュリティの柱におけるベストプラクティス
分野質問ベストプラクティス
セキュリティ SEC 1. ワークロードを安全に運用するには、どうすればよいですか?
アカウントを使用してワークロードを分ける
AWS アカウントのセキュリティを確保する
管理目標を特定および検証する
セキュリティ脅威に関する最新情報を入手する
情報セキュリティのレコメンデーションに関する更新情報を入手する
パイプラインのセキュリティコントロールのテストと検証を自動化する
脅威モデルを使用してリスクを特定し、優先順位を付ける
新しいセキュリティサービスと機能を定期的に評価および実装する
Identity and Access Management
SEC 2. ユーザー ID とマシン ID はどのように管理したらよいでしょうか?
強力なサインインメカニズムを使用する
一時的な認証情報を使用する
シークレットを安全に保存して使用する
一元化された ID プロバイダーを利用する
定期的に認証情報を監査およびローテーションする
ユーザーグループと属性を活用する
SEC 3. 人とマシンのアクセス許可はどのように管理すればよいでしょうか?
アクセス要件を定義する
最小権限のアクセスを付与する
緊急アクセスのプロセスを確立する
アクセス許可を継続的に削減する
組織のアクセス許可ガードレールを定義する
ライフサイクルに基づいてアクセスを管理する
パブリックおよびクロスアカウントアクセスの分析
リソースを安全に共有する
検出 SEC 4. セキュリティイベントをどのように検出し、調査していますか？
サービスとアプリケーションのログ記録を設定する
ログ、結果、メトリクスを一元的に分析する
イベントへの応答を自動化する
実用的なセキュリティイベントを実装する

分野質問ベストプラクティス
インフラストラクチャ保護
SEC 5. ネットワークリソースをどのように保護しますか?
ネットワークレイヤーを作成する
すべてのレイヤーでトラフィックをコントロールする
ネットワーク保護を自動化する
検査および保護を実装する
SEC 6. コンピューティングリソースをどのように保護していますか?
脆弱性管理を実行する
攻撃領域を削減する
マネージドサービスを活用する
コンピューティング保護を自動化する
ユーザーが遠距離でアクションを実行できるようにする
ソフトウェアの整合性を検証する
データ保護
SEC 7. どのようにデータを分類していますか?
ワークロード内のデータを特定する
データ保護コントロールを定義する
識別および分類を自動化する
データのライフサイクル管理を定義する
SEC 8. 保管時のデータをどのように保護していますか?
安全なキー管理を実装する
保管中に暗号化を適用する
保管時のデータの保護を自動化する
アクセスコントロールを適用する
人をデータから遠ざけるメカニズムを使用する
SEC 9. 転送時のデータをどのように保護していますか?
安全な鍵および証明書管理を実装する
伝送中に暗号化を適用する
意図しないデータアクセスの検出を自動化する
ネットワーク通信を認証する
インシデント対応 SEC 10. インシデントの予測、対応、復旧はどのように行いますか?
重要な人員と外部リソースを特定する
インシデント管理計画を作成する
フォレンジック機能を備える
封じ込め機能を自動化する
アクセスを事前プロビジョニングする
ツールを事前デプロイする
ゲームデーを実施する
セキュリティの柱におけるベストプラクティス

セキュリティの柱における 10 の質問
再掲

最低限おさえておきたいセキュリティの 7 項目

Sec1 :
• AWS ルートアカウントには必ず
MFA (多要素認証) を設定し、最小限の利用に留める (極力使用しない)
• AWS アカウントの分離を検討する

1. AWS ルートアカウントには必ず MFA (多要素認証)
を設定し、最小限の利用に留める(極力使用しない)
AWS ルートアカウントとは？
• アカウント作成時のメールアドレスと設定したパスワードでのサインイン
• アカウントの全ての AWS サービスとリソースへの完全なアクセス権限を持つ
AWS ルートアカウントは MFA を設定し、”極力”利用しない
• 十分に強度の強いパスワードを設定したの上、
多要素認証 (MFA) で保護し、通常は極力利用しないような運用を推奨
• Security Credential のページから Access Key を削除する
(ただしAccess Keyを使用していないか確認が必要)
一部、ルートアカウントが必要となる操作もある
(https://docs.aws.amazon.com/ja_jp/general/latest/gr/aws_tasks-that-require-root.html)

1. AWS ルートアカウントには必ず MFA (多要素認証)
を設定し、最小限の利用に留める(極力使用しない)
ルートアカウントではなく IAM を利用する
AWS Identity and Access Management (IAM)とは？
• AWSリソースへのアクセスを安全に制御するためのサービス
以下の機能を提供
ユーザ/認証情報管理
• IAMユーザ / パスワード
• MFA (多要素認証)
• 認証情報のローテーション
AWS リソースへの安全なアクセス
• IAMロール
アクセス権限管理
• IAMグループ
• IAMポリシー

多数のシステムをどのように管理するか
• AWS で稼働するシステムの増加
• 単一 … そのシステムの管理者が AWS 自体の管理も行う
• 数個 … 共通基盤チームが AWS 自体の管理と個別システムの監査を行う
• 多数 … 仕組みなしにすべてのシステムを管理するのは困難
• 仕組み
• マルチアカウント化
• IAM やタグなど権限管理の簡素化、強制化
• AWS 環境提供の自動化
• ログの集約や保護の実施
• 共有サービス利用のためのネットワーク構成
1. AWS アカウントの分離を検討する

環境ビジネス推進
課金
部門単位や
システムの単位で
AWSのコストが
明確に分離できる
開発、テスト、本番
などの環境を
セキュリティや
ガバナンス、規制の
ために分離できる
（PCIなど）
ワークロード
外部向け/社内向け
サービスや、
リスクやデータ分類、
顧客の違いなどに
応じてワークロード
を分離できる
事前定義された
ガバナンスフレーム
ワークの中で
特定のビジネス部門
に対する権限の委譲
が行える
アカウント分割で VPC だけでなく API のレベルで環境を分ける

AWS がご提供するマルチアカウント管理ソリューション
AWS Control Tower
AWS Organizations

マルチアカウント管理のフレームワーク
AWS Cloud
AWS Organizations
コア Organizational Units (OUs)
セキュリティインフラストラクチャ
Δ 共有
サービス
Δ ネットワーク
追加の OUs

「Landing Zone」の実装
Landing Zoneとは
• セキュアで事前設定済みのAWSアカウントを提供する仕組みの総称
• ツールを活用してスケーラブルかつ高い柔軟性を提供
• ビジネスのアジリティとイノベーションを実現
• 実装1: AWS Control Tower
• AWSサービスとして提供される Landing Zone （※東京リージョンは2020/11 時点で未対応）
• 容易に利用開始できるが、カスタマイズに制限あり
• 既存アカウントにも適用できるようになった
• 実装2: 独自実装の Landing Zone
• マルチアカウント戦略に基づき独自に実装する Landing Zone
• 自社の方針にしたがって自由にカスタマイズ可能
• AWS Config 適合パックを用いて、
Control Tower の発見的ガードレールを適用可能
2020/04〜
2020/04〜

Sec2 :

2. ユーザー ID とマシン ID
ユーザー ID
• 管理者、開発者、オペレーター、アプリケーションのエンドユーザーは、AWS 環境とアプリケーションにアクセスで
きる ID が必要です。これらのユーザーは、あなたの組織のメンバー、または共同作業を行う外部ユーザーで、ウェブ
ブラウザ、クライアントアプリケーション、モバイルアプリ、インタラクティブなコマンドラインツールを介して AWS
リソースを操作します。
マシンID
• ワークロードアプリケーション、運用ツール、コンポーネントには、データ読み取りなどのため、AWS のサービスに
リクエストを送信できる ID が必要です。このような ID には、Amazon EC2 インスタンスや AWS Lambda 関数など、
AWS 環境で実行されているマシンが含まれます。また、アクセスを必要とする外部関係者のマシン ID を管理すること
もできます。さらに、AWS 環境にアクセスする必要があるマシンが AWS 外にある場合もあります。
AWS ワークロードを安全に運用するために、2 種類の ID を管理する

• SAMLやOIDCを用いたIDフェデレーションをサポート
• 外部のアイデンティティに、IAMロールのセッションを用いてAWSリソースへのアクセスを可能とする
AWSアカウントにおけるシングルサインオン
2.一元化された ID プロバイダーを利用し、
AWS Cloud
IDプロバイダー(IdP)
AWS Cloud
AWS Cloud
サービスプロバイダー(SP)
事前の信頼関係
認証
ロールの引き受け
IAMロール
ユーザー
（外部のアイデンティティ）

IDフェデレーション with SAML
AWS マネジメントコンソール
SAML 用の AWS
サインインエンド
ポイント
ユーザーがポータルサイト
をブラウジングする
ユーザーを
認証する
クライアントを
コンソールに
リダイレクトする
1
2
3 4
6
5
企業データセンター AWS Cloud (サービスプロバイダー)
ポータルサイト/
IDプロバイダー
(IdP)
アイデンティティ
ストア
属性情報に基づいて
ロールの一時セキュリ
ティ認証情報を生成
SAMLアサーションをポスト
ユーザー
STS から一時
セキュリティ
認証情報を送信
認証応答として
SAMLアサーション
を受信する

複数の AWS アカウントへのログインを一元化したい場合
AWS Single Sign on (SSO)

マスターAWSアカウント
AWS Organizations
AWS Single Sign-On
AWS Directory
Service
Active
Directory
設定
ディレクトリ接続
オンプレミス
メンバーアカウント #1 メンバーアカウント #N
フル機能を有効にした
AWS Organizations を通じて
組織内のAWSアカウントを指定
IAMポリシーと同じ⽂法とツールで
パーミッションセットを定義
定義とポリシーがメンバーアカウント
に⾃動的に設定される
1
1 3 3
2
3
IAMロール＆
IAMポリシー
IAMロール＆
IAMポリシー
2
AWS SSO で複数の AWS アカウントへのログインを一元化する

AWS SSO で SAML に対応したビジネスアプリケーションにログインする
マスターカウント
AWS Single Sign-On
AWS Directory
Service
ユーザ＆
グループ Active
Directory
ディレクトリ接続アプリ
オンプレミス
2 2
2
1
2
事前定義されているビジネスアプリ
あるいは
カスタムアプリケーションを選択して登録
アプリケーションのメタデータ
を登録
1
3
設定
3 AD 上のユーザやグループに
を割り当て

AWS アカウントへのアクセスに一時的な認証情報を使用する
• 十分に強度の強いパスワードを設定したの上、多要素認証 (MFA) で保護する
• ルートアカウントにも MFA を設定し、通常は極力利用しないような運用を推奨
• Security Credential のページから Access Key を削除する
(ただし Access Key を使用していないか確認が必要)

AWS アカウントへのアクセスに IAM ロールを使う
 IAM ロール
 AWS リソースへの
一時的なアクセスを提供
 静的 AWS 認証情報の必要性を排除
 権限
 IAM ポリシーを使用して定義
管理者 DevOps アプリケーション
Joe
Nate
Josh
Bob
Scott
バッチ
レポート
モニタリング
アプリケーション
ロール
グループ
監査人
外部監査人
社内監査人
セキュリティ
アナリスト
アカウント

AWS アカウントへのアクセスに IAM ロールを使う
 クロスアカウントアクセスにロールを使用すると、
別のアカウントのリソースにアクセスするときに
セキュリティを強化できる
本番
アカウント 2
信頼する側のアカウント
開発
アカウント 1
信頼される側のアカウント
MyRole
ロールによるアクセスを
許可するリソース
信頼ポリシー
アクセス権限ポリシー
 認証情報の共有なし
 認証情報の重複なし
 必要に応じて MFA を使用
リソースにアクセスしようと
しているアカウント
信頼関係
リソースがある
アカウント
IAM ユーザー
Bob
ロールを引き受ける
ための権限ポリシー
1. ロールを作成
する
2. アクセスポリシー
を割り当てる
3. ロールを引き受けるための
権限をユーザーに付与する
VPC VPC

フルマネージド型ディレクトリサービスの活用
AWS Directory Service
• 会社の既存の認証情報を使用して AWS リソースの管理を簡略化する
• 出来ること
 オンプレミスの既存の Microsoft Active Directory に接続する
 AWS クラウドで新しいディレクトリを設定および運用する
• AWS マネージドサービス:
 ソフトウェアをインストールする必要がない
 AWS によって管理される (パッチ、バックアップ、アップグレード)
 可用性を向上させるために、複数のアベイラビリティーゾーンに
またがって自動的にデプロイされる
ドメイン
コントローラー
Microsoft AD
オンプレミス
オンプレミス AD
との信頼関係
Microsoft AD
or
Simple AD
オンプレミス
AWS環境に独立した
ADを構築
ドメイン
コントローラー
AD
Connector
オンプレミス
オンプレミス AD を
参照

Sec3 :

3.
ガードレールの設置
予防的ガードレール
• 対象の操作を実施できないようにするガードレール
• Organizations Service Control Policy （SCP）で実装する
発見的ガードレール
• 望ましくない操作を行なった場合、それを発見するガードレール
• 管理しつつ開発のスピードを上げるために効果的
• AWS Config Rulesで実装する

3.
AWS Organizations SCP の検討
• AWSリソースや API へのアクセス制限を実現
 呼び出しを許可する API を定義 – 許可リスト
 呼び出しを禁止する API を定義 – 禁止リスト
• ローカルの管理者からは上書きできない
• 必要条件だが十分条件ではない
 IAM ユーザーやロールの
権限は SCP と割り当て済み IAM 権限の共有項
 IAM ポリシーシミュレーターは SCP にも利用可能
{
"Version": "2012-10-17",
"Statement":[
{
"Effect": "Allow",
"Action":["EC2:*","S3:*"],
"Resource":"*"
}
]
}
{
"Version": "2012-10-17",
"Statement":[
{
"Effect": "Allow",
"Action": "*:*",
"Resource":"*"
},
{
"Effect":"Deny",
"Action":"S3:PutObject",
"Resource":"*"
}
]
}
許可リスト禁止リスト
AWS
アカウント
AWS
アカウント
AWS
アカウント
SCP SCP SCP
ルート
AWS
アカウント
AWS
アカウント
AWS
アカウント
OU AWS
アカウント
OU
組織(Organization)
OU OU
マスター
アカウント

3.
AWS Config Rules の検討
• 組織のルールから逸脱していないかどうかを評価
• 全体的なコンプライアンスおよびリスク
ステータスの評価、経時的なコンプライアンス
傾向の確認、どの設定変更によってリソースが
ルールに違反したかの特定が可能
• ルールによるリソースの
設定変更の評価結果はダッシュボードで確認可能
https://docs.aws.amazon.com/ja_jp/controltower/latest/userguide/strongly-recommended-guardrails.html

Sec4 :

4.セキュリティ関連のログ取得し、
一元的に監視と分析をする
• AWS CloudTrail のログとAWS Configのログを
ログアカウントの Amazon S3バケットに集約
• 保存バケットのバケットポリシーと
各サービスの送信先設定だけで実現可能
• ログ集約を停止させないよう AWS
Organizations SCP も合わせて利用する
AWS Organizations Account
他のアカウント
ログアーカイブアカウント
S3 Bucket
/AWSLogs/<account-id>/CloudTrail
/AWSLogs/<account-id>/Config
CloudTrail AWS Config
AWS Config や AWS CloudTrail を有効化し、ログを一元的に集約する

Amazon GuardDuty とは
Amazon GuardDuty を使用する

Amazon GuardDuty を使用する
悪意のある
スキャン
AWS リソースへの
脅威
アカウントへの
脅威
Amazon
GuardDuty
VPC flow
logs
DNS Logs
CloudTrail
HIGH
MEDIUM
LOW
Findings
データソース
脅威の種類

AWS Security Hub を活用する
AWSセキュリティサービス
セキュリティパートナー
ソリューション
AWSサービスによ
る対応アクション
検出結果
パートナーソリューション
による対応アクション
他にも様々なパートナー
AWS
Security Hub
Amazon
Detective
その他 AWS サービス

各サービスの検出結果を Security Hub に送信し、一元的に可視化
Amazon GuardDuty
脅威検知に関する全ての検出結果
Amazon Inspector
セキュリティ評価による全ての検出結果
Amazon Macie
ポリシー違反時の検出結果
AWS IAM Access Analyzer
自身のアカウント内のリソースに対して、
外部からのアクセスを許可するポリシー記述を検出した時の検出結果
AWS Firewall Manager
AWS WAF ポリシーや Web ACL ルールのコンプライアンス非準拠時の検出結果
AWS Shield Advanced によりリソース保護されていない、または攻撃を検知した時の検出結果
AWS Systems Manager Patch Manager
EC2インスタンスがパッチベースラインに基づくコンプライアンスルールに非準拠の時の検出結果

AWS Security Hub と連携するセキュリティパートナー製品例
Firewalls
Vulnerability
MSSP
Endpoint
Compliance
Other
検出結果に基づいた対応アクション
AWS
Security
Hub
Amazon
CloudWatch
Events
Event
(event-
based)
AWS Security Hub へ検出結果を送信
https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-findings-format.html

Sec5 :

5. ネットワークレイヤーを作成する
共通の達成可能要件を持つ
コンポーネントのセグメント化
Public subnet
CDN/WAF
VPC
AWS Cloud
Availability Zone 1 Availability Zone 2
NAT gateway NAT gateway
既存DC
操作ログ
リソース監視
通知
データ暗号化
暗号鍵管理
管理コンソール
変更監視
専用線
接続
DNS
IGW
Private subnet 権限管理
TGW

5. すべてのレイヤーでトラフィックをコントロールする
多層防御アプローチを
用いて複数のコントロールを適用
• セキュリティグループ
ポート 25
(SMTP)
VPC Subnet
EC2
ポート25
(SMTP)
ネットワークACL
セキュリティグループ
Private Subnet
172.16.0.0/24
Public Subnet
172.16.1.0/24
CIDR : 172.16.0.0/16
NACL NACL
SG SG
TGW
インターネット

Sec6 :

6. 脆弱性管理を実行する
Amazon Inspector を活用する
Amazon Inspector

6. 脆弱性管理を実行する
Amazon Inspector を活用した脆弱性管理
AWS Management
Console
AWS Tools
and SDKs
AWS
Command Line Interface
Amazon Inspector
Amazon CloudWatch
AWS CloudTrail
EC2 Instance Agent
VPC
CloudWatch Events
による評価実行のトリガー
Amazon CloudWatch
AWS Lambda
Inspector は Agentを
使ってインスタンスの
評価を実行
評価実行の監査
評価実行に関
するメトリク
スとイベント
評価実行と
結果の取得
AWS
CloudFormation
EC2 インスタンスデプロイ時に
自動的に Inspector 評価を実行
AWS Systems Manager
Run Commandによるパッチの適用や、
パッケージのアップデートの実行
AWS Security Hub
評価結果の
東郷ダッシュボード
での表示

攻撃対象領域を縮小
6. 攻撃領域を削減する
Public subnet
CDN/WAF
VPC
AWS Cloud
Availability Zone 1
Auto Scaling
group
Availability Zone 2
NAT gateway NAT gateway
Web Instance Web Instance
既存DC
操作ログ
リソース監視
通知
データ暗号化
権限管理
暗号鍵管理
管理コンソール
変更監視
DB Master
DNS
Private subnet
DB Secondary
ALB
IGW
専用線
接続
TGW

6.コンピューティング保護を自動化する
C&Cサーバー
との通信を検知
検知結果にある
インスタンスID
を指定
Amazon
CloudWatch
Events
AWS Systems
Manager
Run Command
3rd Party
アンチマルウェア
端末スキャン
Amazon
GuardDuty
マスターアカウント
メンバーアカウント
感染
確定
感染端末の初期対応

C&Cサーバー
との通信を検知
検知結果にある
インスタンスID
を指定
Amazon
CloudWatch
Events
AWS Systems
Manager
Run Command
3rd Party
アンチマルウェア
マルウェア駆除
Amazon
GuardDuty
マスターアカウント
メンバーアカウント
駆除
感染端末のマルウェア駆除

逸脱する操作の検出と対応
Lambda
function
Amazon
CloudWatch
Events
AWS Config
Rule
AWS アカウント
修復アクションを
呼び出す
準拠していない
リソースを検知
AWS Systems
Manager
Automation
仮想サーバ郡を停止
(EC2::StopInstances)
AWS Config
指示
Amazon EC2 Instances
コンプライアンス
違反の評価

逸脱する操作の検出と対応
Lambda
function
Amazon
CloudWatch
Events
AWS Config
Rule
AWS アカウント
呼び出す
リソースを検知
AWS Systems
Manager
Automation
仮想サーバ郡を停止
(EC2::StopInstances)
AWS Config
指示
コンプライアンス
違反の評価

Sec8 :

AWSのサーバーサイド暗号化（SSE）
8.
AWS Storage Services
S3 Glacier Redshift RDS for
Oracle
RDS for
MS-SQL
HTTPS
アプリケーションアプリケーション
• S3, EBS and Redshift・・・サーバーサイド暗号化のオプションあり
• Glacier・・・全てのデータが標準で暗号化
• RDS for Oracle and Microsoft SQL・・・TDE（Transparent Data Encryption）機能で暗号化
EBS

KMS を用いたサーバーサイド暗号化
AWSサービス
+
データキー暗号化されたデータキー
暗号化された
データ
アカウント下の
マスターキー
AWS KMS
1. AWSサービスはデータを暗号化するための暗号鍵を要求します。
2. AWSサービスからの要求は認証を受け、マスターキーを利用する権限があるか確認されます。
3. 新しいデータ暗号化用の鍵が生成され、そのコピーはマスターキーによって暗号化されます。
4. データ暗号化用の鍵（データキー）とマスターキーによって暗号化された
データキーがAWSサービスに渡されます。データの暗号化にはデータキーが用いられ、使用後に鍵は消去されます。
5. 暗号化されたデータキーは後で利用するときのために保管され、元のデータを復号する必要があるときにはKMSに戻されます。
利用者で鍵の生成や
ローテーション、
Enable/Disableや権限設定
等の管理ができる
8.

本日ご紹介したセキュリティの 7 項目

AWS Well-Architected フレームワークの
ベストプラクティスを活用するには ①
 始める前にホワイトペーパーを読む
 質問を通して反復する
 潜在的課題と実施すべきアクションを特定する
 リリース前のレビュー
 リリース後も定期的にレビュー

AWS Well-Architected フレームワークの
ベストプラクティスを活用するには ②
 AWS Well-Architected Labs を活用する
 ハンズオン形式で Well-Architected フレームワークの
ベストプラクティスの適用方法を実践的に学ぶことが出来る
https://www.wellarchitectedlabs.com/

まとめ

まとめ
• AWS Well-Architected フレームワークとは
 10 年以上の経験、数多くのお客様と作りあげた
クラウド設計・運用のベストプラクティス集
• セキュリティの柱におけるベストプラクティスを活用
 10 個の質問とベストプラクティスを活用し、
現状 (As Is) を理解し、将来あるべき姿 (To Be) を検討
• AWS Well-Architected フレームワークのベストプラクティスを学ぶ
 ホワイトペーパーを読む
 AWS Well-Architected Labs 上のハンズオンで実践的に学ぶ

Well-Architectedフレームワークホワイトペーパー
 W-A ホワイトペーパー (※従来より提供していた PDF の更新は 2021/02 で停止)
https://docs.aws.amazon.com/ja_jp/wellarchitected/latest/framework/welcome.html
→いずれも付録 (Appendix) にW-Aツールで扱う
ベストプラクティスの質問が記載されています

Thank You!

AWS Well-Architected Security とベストプラクティス

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à AWS Well-Architected Security とベストプラクティス

Similaire à AWS Well-Architected Security とベストプラクティス (20)

Plus de Amazon Web Services Japan

Plus de Amazon Web Services Japan (20)

Dernier

Dernier (9)

AWS Well-Architected Security とベストプラクティス