AWS 認定ソリューションアーキテクト – プロフェッショナル 合格への道#8

はじめに

出題範囲

• 組織の複雑さを考慮した設計 hb
  • ハイブリッド設計
• 新しいソリューションの設計 s
  • クラウドファースト設計
• 移行方法の理解 m
• コスト管理 c
• 既存のソリューションの継続的な改善 i　
  • 改善案の提案

解いた感じ八割くらいとれてそうだったので何を間違えたか詰めていきます。

学習

3　ds ×

ある会社はalbの背後のec2でアプリケーションを動かしている。増加分のトラフィックによってアプリケーションのパフォーマンスが下がっている。増加分のトラフィックは複数のソースから不正なリクエストが含まれていることが明らかになりました。こういった攻撃を最速で回避するためは？

• cfディストリビューションを作成しelbをオリジン設定。shield　standardを有効に設定
  • 選択
  • 不正解
  • standardを有効にするとは？
  • WebACLを入れないとIPで絞れない
• elbに文字列一致条件を指定したWAFルールを追加して不正リクエストをブロックする。
  • リアルタイムに増加するトラフィックには対応できない
  • WAFルールを割り当てできない
• lambda作成してebのアクセスログから不正なリクエストを特定し、悪意のあるトラフィックのソースIPアドレスをブロックするようにelbに関するWAFルールを更新する。
  • elbにWAFルールは割り当てできない?albを指しているのであれば正解か
• cfでelbをオリジン設定。lambdaでcfから不正なリクエストを特定しelbに関するWAFルール更新。
  • 上記の選択肢と比べてこっちのほうがベターなので正解。
  • Lambda処理で1分間に指定したレスポンスコードが閾値を超えたらWAFのIPブロックリストへ登録
  • 「ログファイル配信のタイミング」によると 「1 時間に最大で数回配信」を記載があります。また、「最大で 24 時間遅れることもあります」 とも記載されています。

Amazon CloudFront

ユースケース

• 静的アセットのキャッシュ
• ライブおよびオンデマンドのビデオストリーミング
• セキュリティ
  • CloudFront は、レイヤー 3 およびレイヤー 4 の DDoS を緩和する AWS Shield、レイヤー 7 を保護する AWS WAF とシームレスに統合されています。さらに、CloudFront では最高度のセキュリティ暗号化を使って TLS 接続のネゴシエートが行われ、ビューワーは署名付き URL で認証されます。また、高度な機能であるフィールドレベルの暗号化を使用すれば、企業全体で最も機密性が高いデータを保護できます。これにより、アプリケーションスタックで特定のコンポーネントやサービスを使用した場合のみ、それらの情報を閲覧できます。CloudFront は、アクセスを制御する AWS Identity and Access Management (IAM)、設定内容へのアクセスログを記録する AWS CloudTrail、自動的に証明書を更新する Amazon Certificate Manager (ACM) とも統合されています。
• Lambda@Edge でカスタマイズ可能なコンテンツ配信
• 動的コンテンツと API の高速化
• ソフトウェアディストリビューション

CloudFront 経由で配信されるウェブアプリケーションを、DDoS 攻撃からどのように保護できますか?

• AWS のお客様は、追加料金なしで AWS Shield Standard をご利用いただけます。AWS Shield は、AWS で実行しているウェブアプリケーションに対する DDoS 攻撃を防御するマネージド型サービスです。AWS のお客様すべてを対象とする AWS Shield Standard により、SYN/UDP フラッド攻撃やリフレクション攻撃といった最も頻繁に発生する一般的なインフラストラクチャ (レイヤー 3 およびレイヤー 4) 攻撃を防御し、AWS でのアプリケーションの高可用性を保護できます。
• AWS Shield Advanced は、AWS ビジネスサポートと AWS エンタープライズサポートに登録しているお客様を対象とするオプションの有料サービスです。AWS Shield Advanced により、Elastic Load Balancing (ELB)、Amazon CloudFront、および Route 53 で実行しているアプリケーションを標的とする大規模かつ高度な攻撃を防御できます。

Q.CloudFront 経由で配信されるウェブアプリケーションを、どのように保護できますか?

• CloudFront ディストリビューションを AWS WAF (Web アプリケーションファイアウォール) と統合すると、IP アドレス、HTTP ヘッダー、独自 URL 文字列に基づいてルールを設定して、ウェブアプリケーションを攻撃から守ることができます。AWS WAF では、これらのルールを使用して、ウェブアプリケーションに対するウェブリクエストをブロック、許可または監視 (カウント) できます。

WS WAF、AWS Shield、AWS Firewall Manager とは

AWS WAF は、Amazon API Gateway API、Amazon CloudFront、または Application Load Balancer に転送される HTTP および HTTPS リクエストをモニタリング可能にするウェブアプリケーションファイアウォールです。また、AWS WAF は、コンテンツへのアクセスを制御可能にします。リクエストの送信元の IP アドレスやクエリ文字列の値などの、指定した条件に基づいて、API Gateway、CloudFront、または Application Load Balancer はリクエストされたコンテンツまたは HTTP 403 ステータスコード (禁止) のリクエストのいずれかに対応します。CloudFront を設定して、リクエストがブロックされたときにカスタムエラーページを返すこともできます。

• 指定したリクエスト以外のすべてのリクエストを許可する
  • これは、CloudFront または Application Load Balancer に公開ウェブサイトのコンテンツを提供するが、攻撃者からのリクエストをブロックする場合
• 指定したリクエスト以外のすべてのリクエストをブロックする
  • 制限されたウェブサイトのコンテンツを提供する場合
  • ユーザーは、ウェブサイトをウェブリクエストのプロパティ (ウェブサイトを参照するために使用する IP アドレスなど) によって簡単に識別できるようになります。
• 指定したプロパティに一致するリクエストをカウントする
  • 指定したプロパティに一致するリクエストをカウントする
  • ウェブリクエストの新しいプロパティに基づいてリクエストを許可または拒否する場合は、まず、それらのプロパティに一致するリクエストを許可または拒否せずにカウントするように、AWS WAF を設定できます。これにより、ウェブサイトへのすべてのトラフィックをブロックするように AWS WAF を誤って設定していないことを確認できます。正しいプロパティを指定していることが確認できたら、リクエストを許可または拒否するように動作を変更できます。

WAFができること

• 指定した条件を使用した、ウェブ攻撃に対する追加の保護。条件を定義するには、以下のようなウェブリクエストのプロパティを使用します。
  • リクエストの発生元の IP アドレス.
  • リクエスト送信元の国
  • リクエストヘッダーの値
  • リクエストに含まれる文字列 (正規表現パターンと一致する特定の 1 つ以上の文字列)。
  • リクエストの長さ
  • 悪意のある可能性がある SQL コード (SQL インジェクション) の有無
  • 悪意のある可能性があるスクリプト (クロスサイトスクリプティング) の有無
    • cookie情報を利用した不正アクセス（セッションハイジャック）
    • HTMLタグを使った入力フォームによる情報収集
    • 偽サイトを使ったフィッシング詐欺

AWS Shield

• WAF
  • AWS Shield Standard
    • AWS WAF ウェブアクセスコントロールリスト (ウェブ ACL) を使用すると、分散サービス妨害 (DDoS) 攻撃の影響を最小限に抑えることができます。AWS には、DDoS 攻撃に対する保護機能をさらに強化するために、AWS Shield Standard と AWS Shield アドバンスド が用意されています。AWS Shield Standard は自動的に追加料金なしで含まれます。AWS WAF と他の AWS サービスに対して支払い済みの金額を超えてお支払いいただくことはありません
  • AWS Shield Advanced
    • AWS Shield アドバンスド により、Amazon EC2 インスタンス、Elastic Load Balancing ロードバランサー、CloudFront ディストリビューション、Route 53 ホストゾーンで DDoS 攻撃に対する保護が強化されます。AWS Shield アドバンスド には追加料金が発生します。

AWS Firewall Manager

新しいアカウントやリソースを追加するときでも、アカウントとリソース間にルールやその他のセキュリティ保護を自動的に適用します。

AWS WAF

AWS WAF は、Amazon CloudFront ディストリビューション、Amazon API Gateway API、または Application Load Balancer に転送される HTTP(S) リクエストをモニタリングできるウェブアプリケーションファイアウォールです。AWS WAF では、コンテンツへのアクセスを制御することもできます。クエリ文字列からの実行またはクエリ文字列の値をリクエストする IP アドレスのような、指定した条件に基づいて、Amazon CloudFront ディストリビューション、Amazon API Gateway API、または Application Load Balancer はリクエストされたコンテンツまたは HTTP 403 ステータスコード (禁止) のリクエストのいずれかに対応します。CloudFront を設定して、リクエストがブロックされたときにカスタムエラーを返すこともできます。

「AWS上のセキュリティ対策をどういう順序でやっていけばいいか」という話をしました~Developers.IO 2019 Security登壇資料~
https://dev.classmethod.jp/articles/how-to-aws-security-with-3rd-party-solutions/

AWS再入門2019 AWS WAF編
AWS WAFの基本

AWS WAFはALB、CloudFront、API Gatewayに割り当てて利用

WebACLを作ってalb.cf.apigatewayに割り当てて守る。
WAFで作れるルールは以下。

• IP制限

  • IP制限には、管理系ページへのアクセス制限とブラックリストの2種類があります。管理系ページへのアクセス制限では、「http://example.jp/admin以下」はオフィスからのみアクセスできるようにし、管理ページ以外の「http://example.jp/」などはどこからでも接続を許可するといったユースケースがあります。ブラックリストでは、IPアドレスのブラックリストを用意し、一致する場合に通信を遮断します。ブラックリストは、以下のようにして作成します。

• 自分で作成

  • 過去のログなどからリストを作成

• アクセスログから、Lambdaで自動生成
  Amazon KinesisとAWS WAFを利用して、サーバレスでリアルタイムな侵入防止システムを作ってみた
  https://dev.classmethod.jp/articles/ids-with-kinesis-waf/
  

• 外部のreputation listを利用

• WafCharm

  • CSC社が持つIPレピュテーションを利用
  • Webサイトに対する攻撃をAIで学習することにより最適なAWS WAFルールを自動運用するサービスです。CSC社が提供しています。

• レートベースのルール

  同一IPアドレスからの接続数を制限できます。仮に閾値を100に設定したら、直前の5分間で100件を超えるリクエストのあったIPアドレスを自動的にブラックリストに登録し、一定時間遮断します。一定時間経過すると、ブラックリストから外します。ログインページのように特定ページにのみルールを適用するといったことも可能です。

• 特定の脆弱性に関するルール

  XSSやSQLインジェクションなど、WEBアプリケーションの脆弱性に関するルールを作成できます。

• 悪意のあるhttpリクエストかを確認するルール

  サイズ制約条件を使えば、httpリクエストの各要素の長さを判定できます。閾値を超える場合は、悪意のある通信と判断しブロックします。正規表現一致条件を使えば、攻撃と思われる文字列が含まれていないかを確認できます。

AWS BlackBelt AWS上でのDDoS対策

4　cc ×

プロダクションアカウントで承認されていないサービスの利用を禁止して管理オーバーヘッドを最小限にしたい。

• 一括請求機能を有効にした新組織を作成する。本番アカウントと検証アカウントのOUを作成する。未承認のサービスへのアクセスを拒否するIAMロールを本番アカウントのサブアカウントに対して適用

  • IAMロールで管理するのであれば組織を作る意味がない

• すべての機能を有効にした新組織を作成する。未承認のアクセスを拒否するIAMロールを本番アカに対して適用する。

  • IAMロールで管理するのであれば組織を作る意味がない

• 全ての機能を有効にした新組織を作って、本番用OUとそれ以外のOUの二つを作る。SCPをつくって本番OUに適用

  • 正解

• 一括請求機能を有効にした組織を作る。本番用OUとそれ以外のOUの二つを作る。SCPをつくって本番OUに適用

  • 選択
  • 不正解
  • コンソリ機能だけだとSCPを使って他を管理できない

AWS Organizations を実際に初めてみる第一歩

AWS OrganizationsのSCP（サービスコントロールポリシー）を理解する

AWS Organizations とは何ですか？

AWS Organizations には以下の機能があります。

• AWS アカウントのすべての一元管理
• すべてのメンバーアカウントの一括請求
• 予算、セキュリティ、コンプライアンスのニーズを満たすアカウントの階層的なグループ化
  • アカウントを組織単位 (OU) にグループ化し、各 OU に異なるアクセスポリシーをアタッチすることができます。たとえば、特定の規制要件を満たす AWS サービスにのみアクセスする必要があるアカウントがある場合、それらのアカウントを 1 つの OU に入れることができます。その後、それらの規制要件を満たさないサービスへのアクセスをブロックする OU にポリシーをアタッチすることができます。OU は、他の OU 内に 5 レベルまでネストできるため、アカウントグループを柔軟に構成できます。
• 各アカウントがアクセスできる AWS サービスと API アクションのコントロール
  • 組織のマスターアカウントの管理者は、サービスコントロールポリシー (SCP) を使用して、組織内のメンバーアカウントの最大アクセス権限を指定できます。SCP を使用すると、各メンバーアカウントのユーザーとロールがどの AWS サービスリソースおよび個々の API アクションにアクセスできるかを制限することができます。また、AWS のサービス、リソースおよび API アクションへのアクセスをいつ制限するかの条件も定義できます。これらの制限は、組織内のメンバーアカウントの管理者よりも優先されます。AWS Organizations がメンバーアカウントのサービス、リソース、または API アクションへのアクセスをブロックすると、そのアカウントのユーザーまたはロールはアクセスできません。このブロックは、メンバーアカウントの管理者が IAM ポリシーで明示的にそのようなアクセス許可を付与した場合でも有効なままです。
• 組織のアカウント内のリソース間でタグを標準化するためのヘルプ
• AWS Identity and Access Management の統合とサポート (IAM)
  • IAM は、個々のアカウントのユーザーとロールを細かくコントロールします。AWS Organizations は、アカウントまたはアカウントのグループが実行できるユーザーとロールをコントロールできるようにして、そのコントロールをアカウントレベルに展開します。結果として得られるアクセス許可は、アカウントレベルで AWS Organizations によって許可されるものと、そのアカウント内のユーザーまたはロールレベルで IAM によって明示的に付与されるアクセス許可との論理的な共通部分です。つまり、ユーザーは AWS Organizations ポリシーと IAM ポリシーの両方で許可されているものだけにアクセスできます。どちらかがオペレーションをブロックすると、ユーザーはそのオペレーションにアクセスできません。

AWS Organizations の用語と概念

• Organization
  • 1 つの単位として管理できるように、AWS アカウントを 統合するために作成するエンティティ。AWS Organizations コンソールを使用して、組織内のすべてのアカウントを一元的に表示および管理できます。組織には、1 つのマスターアカウントと、ゼロ以上のメンバーアカウントを含みます。最上部が ルートの階層ツリーを模擬した構造のアカウントや、ルート下に作られた組織単位を整理できます。各アカウントは、ルートに直接含めるか、階層内の OU のいずれかに配置することができます。組織には、有効にする機能セットによって決定された機能を含みます。
• ルート
  • 組織のすべてのアカウントが設定された親コンテナポリシーをルートに適用する場合は、組織内のすべての組織単位 (OU) とアカウントに適用されます
• 組織単位 (OU)
  • ルート内のアカウントのコンテナです。また、OU は他の OU に含めることもでき、上下反転したツリーのような階層を作成できます。最上部にはルートがあり、下に向かって OU の枝が広がり、先端にはツリーの葉であるアカウントがあります。階層内のノードのいずれかにポリシーをアタッチすると、その配下にあるすべての枝 (OU) や葉 (アカウント) に適用されます。OU は、厳密に親を 1 つ持つことができ、現在、各アカウントを厳密に 1 つの OU のメンバーにすることができます。
• アカウント
  • AWS リソースを含む標準の AWS アカウント。1 つのアカウントにポリシーをアタッチして、そのアカウントのみ制御
    • マスタ
    • メンバ
• 招待
  • 別のアカウントを組織に招待するプロセスです。招待は、組織のマスターアカウントによってのみ発行できます。招待は、招待されるアカウントに関連付けられたアカウント ID または E メールアドレスに送られます。招待済みのアカウントによって招待が承認されると、そのアカウントが、組織のメンバーアカウントになります。一括請求機能のみのサポートから、組織のすべての機能のサポートへの変更にすべてのメンバーが承認する必要が出てきた場合に、現在のすべてのメンバーアカウントに招待を送信することもできます。招待は、ハンドシェイクを交換するアカウントによって行われます。AWS Organizations コンソールで作業している場合、ハンドシェイクが表示されないことがあります。ただし、AWS CLI または AWS Organizations API を使用する場合は、ハンドシェイクを直接操作する必要があります。
• ハンドシェイク
  • 二者間で情報を交換する複数ステップのプロセスです。AWS Organizations の主な用途の 1 つは、invitations の基盤実装として提供することです。ハンドシェイクメッセージは、ハンドシェイクの開始者と受信者の間で受け渡しと応答が行われます。メッセージは、両方の当事者が確実に現在のステータスを把握できる方法で受け渡しされます。また、ハンドシェイクは、一括請求機能のみのサポートから、AWS Organizations で提供されるすべての機能のサポートへ組織を変更する際にも使用されます。通常、ハンドシェイクは、AWS Organizations API または AWS CLI などのコマンドラインツールを使用する場合にのみ、直接交換する必要があります
• 利用可能な機能セット
  • すべての機能
    • AWS Organizations で利用できるデフォルトの機能セットです。一括請求のすべての機能だけでなく、高度な機能を使用して、組織のアカウントを詳細に制御できます。たとえば、すべての機能が有効な場合、組織のマスターアカウントは、メンバーアカウントより完全に制御できます。マスターアカウントでは、サービスやアクションを制限する SCP を適用し、アカウントのユーザー (ルートユーザーを含む) やロールがアクセスできるサービスおよびアクションを制限できます。マスターアカウントは、メンバーアカウントが組織を離れるのを防ぐこともできます。すべての機能を有効にして組織を作成するか、組織の設定を一括請求機能 (コンソリデーティッドビリング) のみのサポートからすべての機能のサポートに変更することができます。すべての機能を有効にするには、招待済みのすべてのメンバーアカウントを使用して、マスターアカウントでプロセスを開始する際に送信される招待を承認し、変更を承認する必要があります。
  • 一括請求 (コンソリデーティッドビリング
    • この機能を利用すると、請求機能を共有できますが、AWS Organizations の高度な機能は含まれません。たとえば、ポリシーを使用して、異なるアカウントのユーザーとロールが実行できることを制限することはできません。高度な AWS Organizations 機能を使用するには、組織のすべての機能を有効にする必要があります。
• サービスコントロールポリシー (SCP)
  • ユーザーやロールが、SCP による影響を受けるアカウントで使用できるサービスやアクションを指定するポリシーです。アクセス許可が付与されない点を除き、SCP は IAM アクセス許可ポリシーと類似しています。代わりに、SCP は組織、組織単位 (OU) あるいはアカウントに最大アクセス権限を指定します。SCP を組織の root あるいは OU にアタッチすると、SCP はメンバーアカウント内のエントリのアクセス権限を制限します。
• 許可リストと拒否リスト
  • ホワイトリスト
    • フルアクセスを外して新しくポリシーを作成して運用
  • ブラックリスト
    • 最初からついてるフルアクセスは外さずに明示的に拒否するアクションを指定する

5 mp

オンプレMYSQLからAWSへの移行を検討している。クライアントアプリの増加でDBのパフォーマンスが低下している。DBサイズは20TBですが将来的に毎年4TB増える見込み。二つ選べ

• ストレージとIO向けに高速化されたEC2インスタンスで稼働しているMYSQLを使用する。
  • DB on EC2はスケールがめんどくさい
  • auroraと比較して運用コストが高い
• Aurora MYSQL MultiAZ を使う
  • 正解
• RDS ORACLE MultiAZ を使う
  • oracleを選定する根拠がない
• AWS DMSを使用してデータを移行する
  • 正解
• mysqldumpユーティリティを使用してデータを移行する

Amazon Aurora

クラウド向けに構築された、MySQL および PostgreSQL と互換性のあるリレーショナルデータベースです。商用データベースと同等のパフォーマンスと可用性を、10 分の 1 のコストで実現します。

利点

• 優れた性能と拡張性
  • 標準的な MySQL と比べて 5 倍のスループット、標準的な PostgreSQL と比べて 3 倍のスループットを実現しましょう。商業用データベースと同等のパフォーマンスを、10 分の 1 のコストで実現します。変更の必要に応じて、小さなインスタンスタイプから大きなインスタンスタイプに、データベースデプロイを簡単にスケールアップ/スケールダウンできます。
  • もしくは、Aurora Serverless が自動的に処理します。
    • Amazon Aurora (MySQL 互換エディションおよび PostgreSQL 互換エディション) のオンデマンド自動スケーリング設定
    • Aurora Serverlessが一般利用可能になったので試してみた
      • https://dev.classmethod.jp/articles/aurora-serverless-mysql-generally-available/
  • また、読み取りのキャパシティーとパフォーマンスをスケールするために、3 つのアベイラビリティーゾーン間でレイテンシーの低いリードレプリカを最大 15 個追加できます。Amazon Aurora のストレージは、必要に応じて、データベースインスタンスごとに最大 64 TB まで自動的にスケールされます
• 高可用性と耐久性
• 高い安全性
• MySQL および PostgreSQL との互換性
• フルマネージド型
• 移行サポート