【Partner-Hosted 編】ファンデーショナルテクニカルレビュー (FTR) のチェックリスト解説

この記事では、AWS ファンデーショナルテクニカルレビュー (以下、FTR) でチェックされるポイントをご紹介します。FTR についてご存知のない方、またはまずレビューの進め方について知りたいという方は、ブログ記事「AWS ファンデーショナルテクニカルレビュー (FTR) とは」をご覧ください。

ソリューションのタイプ

FTR ではレビュー対象となるソリューションの種類に応じてチェックする観点が異なります。大きく３つのタイプがあり、①パートナーが自身の保有する AWS アカウントにシステムをデプロイしエンドユーザーにサービスとして提供するような Partner-Hosted タイプ (例: SaaS)、②エンドユーザーが自分たちの保有する AWS 環境でパートナーから提供されているアセットを元にシステムを構築していく Customer-Deployed タイプ (例: AMI や AWS CloudFormation テンプレートの提供)、③それ以外の Others (例: AWS Marketplace 経由で販売している製品) があります。

Partner-Hosted タイプでは、AWS アカウントの管理やシステム構成が AWS が推奨するベストプラクティスに沿って構築および運用されているかをチェックしますが、Customer-Deployed タイプではパートナーがエンドユーザーに対して提供するシステムの構築ガイド (デプロイメントガイド) をご提出いただき、分かりやすいガイドになっているか、推奨されている項目が記載されているかといったチェックを行います。見るべき観点とチェック項目が大きく異なりますので、本稿ではまず Partner-Hosted タイプにフォーカスしてチェックリストの内容を解説していきます。

なお、チェックリストは AWS パートナーセントラル からダウンロード可能です。Partner-Hosted に関しては翻訳版が提供されている場合もあるので、Japanese を選択して日本語版のチェックリストをご覧ください  (※日本語切り替え後は必ずチェックリストのバージョンをご確認ください。英語版でのみ新しいバージョンが利用可能な場合があります)。Customer-Deployed の日本語版をご希望のお客様は AWS の担当者にお問い合わせください。

FTR 要件

※以降は 2024 年 2 月 26 日現在の最新版 (Feburary 2024 – 2024_q1_v1) のチェックリストを元にした解説となります。不定期にチェックリストはアップデートされるので、レビューの際は必ず最新版のチェックリストをご確認ください。

FTR ではセキュリティ、信頼性、オペレーショナルエクセレンスという３つの観点に基づいてソリューションの状態を検証します。チェックリストは複数のカテゴリから構成され、各カテゴリに 1 つ以上のチェック項目が含まれる形になっています。Partner-Hosted タイプのカテゴリ一覧は以下になります。

• Partner-Hosted FTR 要件
  1. ホスティング
  2. サポートレベル
  3. アーキテクチャレビュー
• アーキテクチャおよび運用コントロール
  4. AWS ルートアカウント
  5. AWS からの連絡
  6. アイデンティティおよびアクセス管理
  7. 運用セキュリティ
  8. ネットワークセキュリティ
  9. バックアップと復元
  10. レジリエンス
  11. Amazon S3 バケットアクセス
  12. クロスアカウントアクセス
  13. 機密データ
  14. 規制遵守の検証プロセス

レビュー通過の条件としては全ての項目に準拠することが必須となっていますが、ソリューションの性質によってはレビュー不要となる項目もあります。例えば「クロスアカウントアクセス」は、エンドユーザーの AWS アカウントへのアクセスに関する項目ですが、エンドユーザーの AWS アカウントへアクセスすることがないソリューションの場合は、レビューの対象外としてスキップされます。

また、以下の条件を満たしている場合は「アーキテクチャおよび運用コントロール」に含まれる要件をすべてスキップすることが可能です。

• 過去 12 ヶ月以内に AWS の社員と一緒に AWS Well-Architected レビューを実施していること
• 上記レビューの結果として、セキュリティ、オペレーショナルエクセレンス、信頼性の柱すべてで高リスクが 0 であること
• 証跡となるレポートを提出すること (AWS Well-Architected Tool から出力可能)

これは、Well-Architected レビューに含まれるベストプラクティスと FTR の要件には多くの共通性があることや、パートナーの負担を減らしてレビューを効率化するための措置です。求められる考え方や対応の難易度に大きな差はありませんので、自社の状況に合った方をご選択ください。また、Well-Architected レビューで要件をスキップする場合は、FTR の有効期限はその Well-Architected レビューを実施した日から 3 年間になります。FTR の完了日からではない点にご注意ください。

それではここから各カテゴリで求められる要件と、背景にある AWS の思想、ベストプラクティスについて見ていきましょう。

Partner-Hosted FTR 要件

1. ホスティング

まずは FTR を実施しようとしているソリューションが、「ソリューションのタイプ」のうち、Partner-Hosted タイプであることを確認しましょう。判断が難しい場合は、AWS の担当者にご相談ください。

もう一つ重要な確認ポイントとして、FTR を実施するソリューションは、全ての重要なコンポーネントが AWS 上に構築されている必要があります。そのサービスやアプリケーションが停止した場合、ソリューション全体の稼働に影響するようなコンポーネントは、重要なコンポーネントになります。ただし、例外としてコンテンツデリバリーネットワーク (CDN) やドメインネームシステム (DNS) のようなエッジサービスおよびコーポレートアイデンティティプロバイダーについては、AWS 以外の外部サービスを利用することができます。また、利用している外部サービス自体が FTR の認定を取得している場合も、同様に利用可能です。セルフアセスメントシートには、利用している外部サービスをすべて記載してください。

2. サポートレベル

全ての本番稼働 AWS アカウントにおいてビジネスサポート以上に加入することが要件となっています。「全ての」というのは、サービス提供に欠かすことのできないコンポーネントが稼働している、またはアセットを配信しているアカウント全般を指します。例えば、何らかのアプリケーションが動作している環境はもちろん、ユーザーに配布しているインストーラー、ファイル、画像などのデータが保存されているアカウントなども該当します。

これは、ユーザーに対してより安定したサービス提供を行えるようにするためです。例えば、ビジネスサポート以上に加入すると、障害時により迅速なサポートケースへの返信、お客様の事例に即したアーキテクチャガイダンスの提供、AWS Trusted Advisor の全てのチェックが利用可能といったサポートが得られます。本番環境のワークロードを稼働させているアカウントではビジネスサポート、またはビジネスクリティカルなワークロードではさらに上位のエンタープライズサポートにご加入いただくことを推奨しています。

各サポートプランの比較についてはこちらをご覧ください。

3. アーキテクチャレビュー

日々変化する業界のトレンドや新しいベストプラクティスを取り入れるためにも、定期的なアーキテクチャレビューは不可欠です。AWS Well-Architected Framework も不定期にアップデートされ項目の追加や削除が行われるので、たとえシステム構成が変わっていなくても定期的に見直しを行うことは重要です。例えば、新たな脆弱性が発見され気づかない間にセキュリティが低下してしまっているということもあり得ます。また、新たな AWS サービスや機能を利用することで、コストの削減やパフォーマンスの向上が見込める場合もあります。

FTR の要件としては、アーキテクチャレビューを少なくとも年に一回、定期的に実施する計画を組織内で立てていただくことが必要になります。「8 月の第一営業日に行う」といった粒度でスケジュールを設定し、形骸化せずに忘れずに実施されるような運用ルールを定義してください。もしプロジェクトに新しいメンバーがいれば、システム全体の状態を把握する機会としてご活用いただくのもよいかもしれません。

基本的には AWS Well-Architected Framework を元にレビューを行うことを推奨しますが、社内に独自に作成した AWS ワークロードに関連するアーキテクチャ標準などのガイドラインがある場合はそちらを利用しても構いません。Well-Architected レビューを行う場合は、AWS のマネジメントコンソールから利用できる AWS Well-Architected Tool に回答を入力していく形で進めます。全ての質問に回答を入力した後に、PDF でレポートを出力してレビュー担当者にメール等で共有してください。

図 1: AWS Well-Architected Tool

Well-Architected レビューはセルフチェックでも行えますが、より理解を深めるために担当ソリューションアーキテクトと一緒に進めていくことをおすすめします。もし担当がいなければ、AWS が認定した豊富な知識と経験を持つ AWS Well-Architected パートナーにご依頼いただくのも一つの方法です。

定期的なアーキテクチャレビューの実施に加えて、セキュリティ責任共有モデルおよびレジリエンス責任共有モデルの確認も必要です。AWS のクラウド上では、セキュリティやコンプライアンスの責任は AWS と利用者の間で共有されます。この共有モデルにおいて AWS は、AWS クラウドで提供される全てのサービスを実行するインフラストラクチャの保護について責任を負います。AWS が「クラウドのセキュリティ」の責任を持つことに対し、利用者はデータの管理、AWS Identity and Access Management (IAM) による適切な権限の適用といった「クラウドにおけるセキュリティ」に対する責任を持ちます。この責任は、ソリューションを構成する AWS のサービスやリージョン、適用される法律や規制など、多くの要因によって変わります。共有モデルは通常二層で表現されますが、データの管理をエンドユーザーが制御するソリューションなどの場合、エンドユーザー、ソリューションを提供するパートナー、AWS の三者で責任を共有するケースがある点にご注意ください。

図 2: AWS の責任共有モデル

FTR を実施する際には、提供するソリューションに共有モデルがどのように適用されるかを確認し、システムアーキテクチャや運用プロセスが適切に設計されているかを確認する必要があります。

アーキテクチャおよび運用コントロール

4. AWS ルートアカウント

AWS のルートユーザーの取り扱いに関する項目が複数含まれています。ルートユーザーはその AWS アカウントに対する全ての操作が行える非常に強力な権限を持っています。アカウントを解約して削除するようなこともできてしまうため、取り扱いには注意が必要です。

具体的にはそもそも使用しないことをおすすめします。個人ごとにアイデンティティを発行して必要な権限を割り当てる運用にしましょう。ルートユーザーの利用は、サポートプランを変更するなどルートユーザーでしか行えない操作に限定します。また、アカウントの侵害を防ぐために多要素認証 (MFA) の設定、ルートユーザーのアクセスキーの削除を行ってください。

また、ルートユーザーにアクセスすることができなくなった場合などインシデントが発生した場合に備えて、あらかじめインシデント管理計画を用意してください。何者かに侵害されてパスワードを変更されてしまった、MFA デバイスを紛失または壊してしまったなどいくつかシナリオはありますが、こういった場合どのような対応をとればよいかご存知でしょうか？実際にこのようなケースが発生した場合、事態は急を要します。一刻も早くアカウントの回復を行い被害を最小限に抑えるためには、何を行えばよいかが明確で素早く作業が行える体制を作っておく必要があります。そのために、あらかじめインシデントに対応する手順や体制が記載された文書を用意してください。また、インシデント発生の有無にかかわらず、対応プロセスを定期的に更新し、実行性を確認するためにリハーサルを実施することを推奨しています。

5. AWS からの連絡

AWS アカウントの代替の連絡先を設定しましょう。こちらはアカウントの連絡先しか設定していないというお客様も多いのではないでしょうか。

図 3: 代替の連絡先

様々なタイミングで AWS はお客様に通知を行いますが、こちらの代替の連絡先を設定すると、それぞれの役割に応じた通知を受け取ることができます。見逃しがちなポイントですが、代替の連絡先 (請求、オペレーション、セキュリティ) を設定しておくと普段の運用が効率的になる場合があります。例えば、請求の連絡先として経理のメールアドレスを設定しておくことで、これまで毎回 AWS アカウントの管理者からメールを転送していた手間をなくすことができるでしょう。

登録するメールアドレスは担当者個人宛でも構いませんが、メールを見逃したり休暇中に緊急で対応が必要なものが届くといったリスクを避けるために、メーリングリストを使用するのがおすすめです。また、言わずもがなですがプライベートで使用している個人のメールアドレスではなく、会社から提供されているドメインのアドレスを使用しましょう。退職した後も連絡が届き続けるといった事態を避けるためです。

代替の連絡先は、AWS Organizations を利用して一括で設定することも可能です。詳しくはドキュメントをご覧ください。

6. アイデンティティおよびアクセス管理

IAM の適切な管理は、AWS アカウント全体のセキュリティを向上させるための要となる非常に重要な項目です。そのため、このカテゴリには最も多くの要件が含まれています。ソリューションを構成するシステムコンポーネントだけでなく、人が使用するアイデンティティも含めて組織全体の運用を改善させるための観点も盛り込まれているため、社内の様々なステークホルダーと協力して対応していきましょう。

ルートユーザーの項目でも触れましたが、基本的に普段の開発/運用業務には個人ごとに発行されたアイデンティティを利用してください。複数人で一つのアイデンティティを共有すると、実際にどのメンバーが行った操作なのか特定することができなくなり、後から証跡を追うことができなくなります。IAM にはユーザー、ロール、グループなど様々なエンティティがありますが、アイデンティティの作成・管理・運用という観点では、原則可能な限り IAM ロールなどによる一時的な認証情報を利用することがベストプラクティスとなっています。

個人 (またはシステム) ごとに IAM ユーザーを発行して永続的なアクセスキーを利用するよりも、シングルサインオンや外部 IdP からのフェデレーション、IAM ロールとの紐付けを利用して一時的な認証情報を利用することでセキュリティを向上させることができます。多くの AWS サービスでは永続的なアクセスキーの代わりに IAM ロールを利用することができます。また、人間が利用するアイデンティティに関しては、各社で利用している IdP をベースにフェデレーションを設定するか、AWS IAM Identity Center を使って ID 管理を行うことを検討してください。複数の AWS アカウントを利用している場合は、AWS Control Tower を導入することで ID 管理も含めた効率的なマルチアカウント運用を実現することもできます。

一般的にセキュリティを向上させるための方法として、強力なパスワードポリシーの適用と MFA の設定は、IAM においても同じく効果的です。忘れずに設定するようにしてください。また、パスワードのローテーションはしているがアクセスキーはずっと同じものを使っているというケースも少なからず見受けられます。アクセスキーも同様に 90 日を目安にローテーションする運用を行いましょう。ただし、システムによる永続的なアクセスキーの使用は、原則 IAM ロールによる置き換えを検討してください。IAM ロールでは短期間で期限が切れる一時的な認証情報を使用するため、誤って認証情報が漏洩した場合のリスクを最小限に抑えることができます。どうしても置き換えることができない場合は、最低 90 日ごとのローテーションや、どこでどのようなキーを利用しているかのインベントリの作成および管理、不正な利用を検知するための CloudTrail ログの監視、悪用時にキーを削除するためのランブックの作成などを実装してください。

図 4: コンソールから IAM ユーザーの状態を確認

各アイデンティティに対して付与するアクセス権限に関しては、最小権限の原則に従って設計してください。実際に使用するサービス、アクション、リソースなどをしっかりと絞り込み、不要に大きな権限が付与されないように注意します。全員に AdministratorAccess や PowerUserAccess のような強力な権限を与えずに、社内でのロール、タスクごとに適切な IAM グループを作成して集中的に管理すると見通しも良くなります。

また、付与されている権限の見直しを定期的かつライフサイクルにおける重要なイベントが発生した際に実施してください。具体的には、メンバーが退職または異動になった際に、アイデンティティの削除やポリシーの変更を定められた運用に従って忘れずに行います。加えて、実施の漏れがないか、ポリシーが現状を反映した最適なものになっているかを確認する定期的な棚卸し作業も必要になります。こちらは FTR の要件としては少なくとも四半期ごとに実施する計画を定めていただくことが求められます。

次にアプリケーション観点の要件になりますが、IAM のアクセスキーやデータベースパスワードなどのシークレットをコードに埋め込むいわゆるハードコーティングは避けてください。このようなシークレットを安全に保存するためのサービスとして、AWS では AWS Secrets Manager や AWS Systems Manager Parameter Store の機能をご活用いただけます。または、転送時および保存時の暗号化、きめ細かいアクセス制御、アクセスログの記録などの機能を備えた AWS パートナーのシークレット管理ソリューションを使うことも可能です。このようなソリューションを利用してセキュアにシークレットを管理し、アプリケーションレイヤーでのセキュリティ向上に努めましょう。

最後に、エンドユーザー/顧客の認証情報の管理についてです。お客様がログイン時に使用する ID、ユーザー名、メールアドレス、パスワードなどの認証情報は必ず暗号化してください。パスワードに関してはハッシュ化も必須になります。アプリケーション側で暗号化するのが難しい場合は、ディスクレベルの暗号化でも問題ありません。お使いのデータベース、ストレージサービスごとに方法は異なりますが、ビルトインの暗号化機能が備わっているものも多いので、詳細は各サービスのドキュメントをご確認ください。

7. 運用セキュリティ

システムを構成するソフトウェアへの新しい攻撃⽅法、脆弱性が発⾒される可能性があるため、時間の経過とともにシステムのセキュリティレベルは低下します。新しい脅威からシステムを保護するために、継続的なセキュリティ対策は欠かせません。日ごろから情報収集を行い、システムへの影響を判断し、対応を行う脆弱性管理が重要になります。

脆弱性管理は「情報収集」「リスク評価」「対応」という 3 段階のプロセスで構成されます。情報収集では新しく発見された脆弱性を確認し、システム内部に脆弱性が存在するかを判断します。脆弱性が存在する場合は、リスク評価のプロセスでその脆弱性がシステムにとってどの程度のリスクになるかを評価します。このとき、脆弱性がどの程度危険か、攻撃手法が容易に再現できるかなどの脆弱性自体の評価と、システムがリモートから攻撃できる構成になっているかといった環境の評価の 2 つの観点で評価する必要があります。最後に、リスク評価をもとに対応を決定します。修正パッチの適用が本格対策となりますが、それまでにファイアウォールなどによって暫定対策を行うこともあれば、リスクが小さいと評価した場合は対応しないという選択もあります。

大切なことは、この一連のプロセスを継続的に行い、新しい脅威に対応し続けることです。一方で、これらのプロセスを迅速に、かつ同じ品質で続けるためには高度なスキルと多くの時間が必要になります。運用コストを抑えながら継続的な脆弱性管理を実現するためには、脆弱性管理の自動化が有効であり、継続的インテグレーション/継続的デリバリー (CI/CD) パイプラインに脆弱性管理を組み込むことが一つの手段となります。また、ソフトウェアのリリース後ではなく、CI/CD パイプラインの早い段階で脆弱性評価を実施することで、検出された脆弱性への対応に優先順位をつけることができます。CI/CD パイプラインの活用を検討してみてください。

CI/CD パイプラインに脆弱性評価を組み込む方法は対象となる AWS サービスによって異なります。例えば、Amazon Elastic Compute Cloud (Amazon EC2)  インスタンスで稼働するソフトウェアの脆弱性を確認するためには Amazon Inspector を活用することができます。AWS サービス以外にも、オープンソース製品や AWS パートナーが提供する製品を使用することもできるので、要件に応じたアプローチを選択しましょう。こちらのブログ記事では、パートナーソリューションを活用した脆弱性管理の一例を紹介しています。FTR の要件としては、依存関係やオペレーティングシステムの脆弱性スキャンとパッチ適用をどれくらいの頻度でどのように実行するか、ソリューションの要件に応じて定めることが求められています。

8. ネットワークセキュリティ

システム外部の脅威からシステムを保護するために、ネットワークセキュリティも重要です。この項目には Amazon Virtual Private Cloud (Amazon VPC) 内のネットワークの分離や、トラフィック制御に関する要件が含まれています。

まずは VPC 内のネットワークが階層化されているか確認しましょう。VPC はサブネットに分割することができ、VPC 外への通信を制御するルートテーブルはサブネット単位で関連付けを行います。例えば、直接インターネットと通信が行えるように、インターネットゲートウェイへの経路を持つルートテーブルに関連付けられたサブネットをパブリックサブネットと呼び、インターネットゲートウェイへの直接の経路を持たないサブネットをプライベートサブネットと呼びます。このように、サブネットごとに VPC 外部との経路を制御することができるため、必要な通信要件に応じてサブネットを分割することで、不正アクセスや意図しないアクセスがあった場合の影響範囲を最小化することができます。

FTR の要件としては、インターネットからのアクセスを必要とするリソース以外が、パブリックサブネットに配置されていないことを確認します。インターネットへのアクセスのみが必要なリソースであれば、NAT Gateway と組み合わせることでプライベートサブネットからインターネットにアクセスすることが可能です。VPC 内のリソースについて、プライベートサブネットに配置することができないか改めて見直してみてください。

サブネットに配置するリソースを確認したら、サブネット単位やサブネット内のリソースごとに必要な通信要件を洗い出し、最低限のトラフィックのみを許可するようにしましょう。サブネットに対するトラフィックはネットワークアクセスコントロールリスト (ネットワークACL) で制御し、サブネット内の EC2 や RDS インスタンスなどのリソースに対するトラフィックはセキュリティグループで制御することができます。

FTR では、全ての EC2 セキュリティグループにおいて最も厳格なルールを実装することが求められます。少なくとも、以下の 2 点についてはご確認ください。

• 全てのセキュリティグループの設定で、SSH トラフィックまたは RDP トラフィックの受信を許可する場合、全ての IP アドレス (0.0.0.0/0) からの受信を許可するルールが存在しないこと
  • 全ての IP アドレスからサーバーを管理するための通信が可能になっていると、悪意のあるユーザーからアクセスされるリスクが増加します。不特定多数からの通信を受ける Web サービスとは異なり、サーバーを管理するための通信は通信元が決まっているはずなので、これらの通信が必要な場合はセキュリティグループの通信元として、特定の IP アドレス範囲、セキュリティグループの ID またはプレフィックスリストの ID を指定してください。
  • 一般的に SSH トラフィックはポート 22、RDP トラフィックはポート 3389 を使用しますが、それ以外のポートについても SSH または RDP 通信のために利用している場合は、通信元を制限する必要があります。
• 全ての VPC のデフォルトセキュリティグループにおいて、全てのトラフィックが拒否されていること
  • セキュリティグループの指定が必要なリソースを作成した際に特定のセキュリティグループを指定しない場合、VPC のデフォルトセキュリティグループが関連付けられます。また、VPC のデフォルトセキュリティグループは削除することができません。デフォルトセキュリティグループによって意図しないアクセス許可を与えることを防ぐため、あらかじめデフォルトセキュリティグループでは、全てのトラフィックを拒否してください。

また、ネットワーク ACL を使用してトラフィック制御を行なっている場合は、そちらも最小限の通信のみを許可するように設定するのがベストプラクティスです。ネットワーク ACL を使用する際は、ネットワーク ACL がステートレスな機能であることに注意してください。セキュリティグループでは特定のトラフィックの受信を許可している場合、セキュリティグループのアウトバウンドのルールの内容に関わらず、受信したトラフィックの戻りの通信は自動的に許可されますが、ネットワーク ACL を利用する場合は、受信したトラフィックの戻りの通信も明示的に許可する必要があります。この点を踏まえて、最小限の通信が許可されるように設定しましょう。

9. バックアップと復元

セキュリティに関する要件が続きましたが、ここから少し信頼性、運用面での話に移ります。このカテゴリには、バックアップの取得とリストアの検証の 2 つの項目が含まれます。

次のレジリエンスの項目にも関係しますが、まずソリューションが満たすべき水準として RTO (目標復旧時間) および RPO (目標復旧時点) が定義されていないと、適切なバックアップ戦略を決めるのが難しくなります。ソリューションの性質、機能、データの種類、障害時の影響度などのビジネス要件から総合的に判断して、最初に決めておくことをおすすめします。

そして定められた RPO に従って定期的に自動でバックアップを取得する仕組みを構成してください。この「定期的」がどれくらいの頻度が適切なのかはお客様のビジネス要件によって異なるため、ソリューションが満たすべき水準とビジネス要件を改めて見直し、それをシステムの運用に落とし込んでみるのが良いでしょう。場合によっては、ロストしても問題ない重要ではないデータ、後から作り直すことができるデータなどはバックアップを取らないという意思決定が正解かもしれません。エンドユーザーにバックアップの責任がある場合には、その旨をドキュメントとして明示し、データのバックアップ方法とその明確な手順を提供する必要があります。

バックアップについて検討が済んだら次はリストアです。バックアップをしっかり取っていてもそれが戻せなければ意味がありません。必ずリストアの検証を行いましょう。本番同様の検証環境などを用意して、できれば同じ程度のデータ量でテストしてみるのがおすすめです。その作業時間が実際に本番でリストアを行うときの目安になります。FTR の要件としては、定期的 (少なくとも年に 1 回程度) かつ大きなアーキテクチャ変更などがあった際にテストを行う運用計画を定義してください。定期的にリハーサルを行うことによって、本番作業時に迷いなく、ミスなく、素早く作業を行うことができるようになります。新しく入ってきたメンバーの育成という観点も重要です。作業に携わる全てのメンバーを適切に巻き込んでいきましょう。

10. レジリエンス

レジリエンスとはシステムが障害に対応し、障害から迅速に復旧する能力のことです。まずはビジネス要件に応じて、提供するソリューションにどの程度のレジリエンスが必要かをご検討ください。レジリエンスを適切に設計するために、ディザスタリカバリ (DR) と一般的な障害に対する可用性の 2 つの観点に分けて考えることが有効です。

DR については、パートナーにとってのディザスタの定義は何か、どこまで備えるのかを明確にする必要があります。アベイラビリティゾーン (AZ) の一つに障害が発生したケースを想定してマルチ AZ 構成を組んでいるお客様もいれば、リージョン全体の障害も想定してマルチリージョンで Active-Standby 構成を用意しているお客様もいらっしゃるかと思います。備えるべきスコープが決まったら、それに対して有効な DR 構成を設計し、RTO および RPO を定めてください。これは必ずしもエンドユーザーに対して公開している情報である必要はなく、組織内部の目標値でも構いません。RPO については前節のバックアップの頻度によって自ずと決まってくるかと思います。

可用性の目標や稼働率 SLA をエンドユーザーと合意する場合、システムのアーキテクチャおよび運用プロセスがそれらを実現できるように設計されていることを確認してください。例えば EC2 インスタンスから構成されるソリューションの場合、可用性の目標に応じて、複数の AZ に EC2 インスタンスをデプロイするケースもあれば、自動的なインスタンスの復旧のみで十分なケースもあります。レジリエンス責任共有モデルを踏まえて、必要な構成がとられていることを確認し、エンドユーザーに対してもその内容を明確にガイダンスしてください。

また、エンドユーザーが自身の責任を理解し、適切にソリューションを利用するために、バックアップ、復元、および可用性に関するエンドユーザーの責任について、製品ドキュメントや契約書のなかで明確に定義する必要があります。バックアップの項目にも記載していますが、ソリューションに保存されたデータをバックアップするためにエンドユーザーが負う責任を説明してください。また、データのバックアップやデータ保護、またはソリューションの可用性を設定するためにエンドユーザーが利用できるオプション機能がある場合はその設定方法を提供してください。

レジリエンスについて RTO/PRO などの指標やその実装方法を整理したら、レジリエンステストを実施しましょう。テストを実施することが、システムが意図したとおりに動作し、期待するレジリエンスを実現できているか確認する唯一の方法です。想定したシステム障害が実際に発生したと仮定して、サーバーの切り替えやデータのリストアなど必要な作業を実施します。FTR の要件としては最低限、偶発的なデータ損失、インスタンス障害、および AZ 障害の発生を想定してテスト行う必要があります。システムが復旧するまでの時間を計測し、復旧したデータの内容を確認して、ともに RTO と RPO を満たせているか評価しましょう。もし目標を満たせていなければ、構成や目標値の見直しが必要になります。この検証をリストアのときと同じく、定期的 (少なくとも年に 1 回程度) かつ大きなアーキテクチャ変更の際に行う運用計画を定めてください。

システム障害が発生した際に、エンドユーザーとどのようにコミュニケーションを行うかも計画しておきましょう。システム障害に関する情報を適切に伝えることで、エンドユーザーの過剰な不安や憶測をケアすることができます。また、復旧までの推定時間や進捗状況を伝えることで、エンドユーザーはシステム障害による影響を回避するために行動できる可能性があります。伝えるメッセージや伝達するチャネル、タイミングなどをあらかじめ戦略的に計画しておくことは、エンドユーザーの信頼を維持することに繋がります。

注意すべき点として、エンドユーザーとのコミュニケーションでは、秘密保持契約 (NDA) の下で AWS から提供された内容を含めないでください。他にも、セキュリティリスクに繋がるシステムの詳細情報など、公開すべきではない情報があるかと思います。エンドユーザーへ提供する情報の取り扱いを誤らないためにも、事前に計画されたコミュニケーションが重要になります。

11. Amazon S3 バケットアクセス

Amazon Simple Storage Service (Amazon S3) バケットのセキュリティについてです。S3 バケットのアクセス制限には大きく分けて 2 つのパターンがあります。インターネットから誰でもアクセスすることができるパブリックと、特定のネットワーク内または許可されたアイデンティティからのみ利用可能なプライベートです。FTR ではそれぞれの S3 バケットに対する適切なアクセスレベルを判断することが求められます。

まずは各バケットがパブリックアクセスが必要なのかそうでないのかを整理しましょう。ユーザーからアクセスできるようにしたいといった要件がある場合は、Amazon CloudFront 経由で配信する構成がおすすめです。この方法ではレスポンスの高速化など様々なメリットを受けられますが、オリジンアクセスコントロール (OAC) を使用してアクセスを制限することで、バケット自体をプライベートに保つことができます。以前からあるオリジンアクセスアイデンティティ (OAI) を利用している場合は、必要に応じてこちらを参考にオリジンアクセスコントロールへ移行することをおすすめします。OAC は OAI の機能に加えて、AWS KMS による S3 サーバー側の暗号化 (SSE-KMS) や S3 に対する動的なリクエスト (PUT/DELETE) をサポートしています。パブリックアクセスが必要なケースというのはそこまで多くはないはずなので、これを機に自社の構成を見直してみるのも良いでしょう。

パブリックアクセスが必要ないバケットには必ずパブリックアクセスブロックを有効化してください。こちらを設定しておくことで、意図せぬオブジェクトの公開を防止できます。

図 5: S3 のパブリックアクセスブロック

12. クロスアカウントアクセス

このカテゴリは、エンドユーザーの AWS アカウントに対してアクセスすることがあるソリューションの場合のみ適用される要件になります。そのような挙動がない場合は読み飛ばしていただいて構いません。

チェック観点はクレデンシャルの受け渡し方法です。まず最初に思いつくのは、エンドユーザーからアクセスキーとシークレットキーを教えてもらいそれをシステムで使用するという方法かもしれませんが、これにはクレデンシャルのローテーション、認可されていない第三者による不正利用など様々な問題が伴います。こちらのブログ記事 (英語) に詳しく記載されていますが、代わりに IAM ロールを用いたクロスアカウントアクセスの仕組みを構築してください。簡単に流れを説明すると、エンドユーザーのアカウントで必要な権限を付与した IAM ロールを作成し、サービス提供側のアカウントに AssumeRole を許可する形になります。

この方法であればクレデンシャルを直接やり取りする必要もなく、セキュアにアカウント間の権限委譲を行うことができます。エンドユーザー側の作業が必要になりますので、どのようなことを行えばよいのか手順を記載したガイド、または作業を自動化した AWS CloudFormation テンプレートなどをご提供ください。もし既にクレデンシャルによるクロスアカウントアクセスを行う仕組みでソリューションを提供している場合、アプリケーションのユーザーインターフェースおよびエンドユーザー向けのドキュメントで、この方法が非推奨であることを明確に記載する必要があります。

FTR の要件としては、ロールの設定方法について注意すべきところがあります。AssumeRole には 外部 ID を必須とします。これは Confued deputy problem と呼ばれる、意図しない第三者によるアクセスを防ぐための仕組みです。エンドユーザーが自身で外部 ID を設定および変更できないように、エンドユーザーには外部 ID の読み取りのみを許可してください。また、エンドユーザーのなりすましや、エンドユーザー間でデータが閲覧できてしまうリスクの発生を防止するために、外部 ID の値はサービス提供側で生成し、全ての外部 ID を一意にする必要があります。

13. 機密データ

機密データの取り扱いに関する要件です。機密データとは何でしょうか？これもお客様によって解釈が異なる概念です。ワークロードの性質に応じて、何を機密データとして特に保護する必要があるか、データのクラス分けを行いましょう。一般的には個人情報 (PII)、保護医療情報 (PHI) などが該当しますが、その詳細な定義も会社によって多種多様です。

クラス分けができたら、機密データに対して適切な保護を検討します。機密データの保存時および転送時は暗号化を必ず行ってください。転送に関しては、外部との通信は暗号化プロトコルの使用が必須で、VPC 内部の通信に関しては必要に応じて使用を検討します。

14. 規制遵守の検証プロセス

最後にコンプライアンスに関する要件です。ソリューション提供のために何らかのコンプライアンス、業界標準を取得する必要のあるソリューションにおいては、そちらを遵守するための内部プロセスの定義が求められます。例えば PCI DSS、FedRAMP、HIPAA などが代表的なものですが、特に取得が義務づけられているようなものがなければレビューは不要となります。

まとめ

FTR では、セキュリティ、信頼性、オペレーショナルエクセレンスに関する様々な観点から詳細にソリューションが検証されます。要件が多く厳しいと感じることもあるかもしれませんが、裏を返せば FTR を通過した製品は、これらの要件を全て満たした AWS お墨付きのソリューションだということです。多くのベストプラクティスを取り入れた、お客様が安心して利用できるソリューションという点を、製品の付加価値としてプロモーションなどにご活用いただくこともできます。また、ここでご紹介したベストプラクティスに準拠することは、アーキテクチャや運用体制の改善という観点で全てのお客様にとってメリットがあるものなので、ぜひ一度レビューを行いディスカッションの機会などにご活用いただければ幸いです。FTR を受けておくべき理由や実際のレビューの雰囲気などが分かるインタビュー記事も公開しておりますので、併せてご覧ください。

【参考情報】

レビューの申請はパートナーセントラルから行えます。

ブログ：AWS ファンデーショナルテクニカルレビュー (FTR) とは

ブログ：パートナーに聞く！FTR 通過を目指すべき理由とは？（前編 | 後編）

ブログ：パートナーに聞く！FTR 通過の対応のコツとは？

本記事は、パブリックセクターパートナーソリューションアーキテクト 山田 磨耶 とパートナーソリューションアーキテクト 櫻谷 広人 による共著です。