AWS JAPAN APN ブログ
【Partner-Hosted 編】ファンデーショナルテクニカルレビュー (FTR)でチェックされるポイントとは？
(2024/2/14) 本記事には一部古い情報が含まれています。最新版のブログ記事『【Partner-Hosted 編】ファンデーショナルテクニカルレビュー (FTR) のチェックリスト解説』をご覧ください。
皆様こんにちは、パートナーソリューションアーキテクトの櫻谷です。
この記事では、AWS ファンデーショナルテクニカルレビュー (以下、FTR) でチェックされるポイントをご紹介します。FTRについてご存知のない方、またはまずレビューの進め方について知りたいという方は、AWS Foundational Technical Review の進め方をご覧ください。
ワークロードのタイプ
FTR ではレビュー対象となるワークロードの種類に応じてチェックする観点が異なります。大きく３つのタイプがあり、①パートナーが自身の保有する AWS アカウントにシステムをデプロイしエンドユーザーにサービスとして提供するような Partner-Hosted タイプ（例：SaaS）、②エンドユーザーが自分たちの保有する AWS 環境でパートナーから提供されているアセットを元にシステムを構築していく Customer-Deployed タイプ（例：マーケットプレイス経由での AMI 提供）、③それ以外の Others があります。
Partner-Hosted タイプでは、AWS アカウントの管理やシステム構成が AWS が推奨するベストプラクティスに沿って構築および運用されているかをチェックしますが、Customer-Deployed タイプではパートナーがエンドユーザーに対して提供するシステムの構築ガイド (デプロイメントガイド) をご提出いただき、分かりやすいガイドになっているか、推奨されている項目が記載されているかといったチェックを行います。見るべき観点とチェック項目が大きく異なりますので、本稿ではまず Partner-Hosted タイプの方にフォーカスしてチェックリストの内容を解説していきます。
なお、チェックリストは AWS パートナーセントラル からダウンロード可能です。こちらは英語のみとなりますが、日本語訳付きのチェックシートを参考としてお渡しすることもできますので、ご希望の際は担当の者にお声がけください。
FTR 要件
※以降は2021年12月23日現在の最新版 (October 2021 – 2021_q4_v1) のチェックリストを元にした解説となります。四半期を目安に不定期にチェックリストはアップデートされますので、レビューの際は必ず最新版のチェックリストをご確認ください。
FTR ではセキュリティ、信頼性、運用上の優秀性という３つの観点に基づいてお客様のワークロードの状態を診断します。チェックリストは複数のカテゴリから構成され、各カテゴリに1つ以上のチェック項目が含まれる形になっています。Partner-Hosted タイプのカテゴリ一覧は以下になります。
- Support Level
- AWS Well-Architected Review
- AWS Root Account
- Communications from AWS
- CloudTrail
- Identity and Access Management
- Backups and Recovery
- Disaster Recovery
- Amazon S3 Bucket Access
- Cross-Account Access
- Sensitive Data
- Protected Health Information
- Regulatory Compliance Validation Process
レビュー通過の条件としては全ての項目に準拠することが必須となっていますが、中にはレビュー不要となる項目もあります。例えば Protected Health Information は保護医療情報 (PHI) の取り扱いに関する項目ですが、PHI を取り扱っていないソリューションの場合は、そもそもレビューの対象外としてスキップされます。
それではここから各カテゴリで求められる要件と、背景にある AWS の思想、ベストプラクティスについて見ていきましょう。
Support Level
全ての本番稼働 AWS アカウントにおいてビジネスサポート以上に加入することが要件となっています。全てのというのは、サービス提供に欠かすことのできないコンポーネントが稼働している、またはアセットを配信しているアカウント全般を指します。例えば、何らかのアプリケーションが動作している環境はもちろん、ユーザーに配布しているインストーラー、ファイル、画像等のデータが保存されているアカウントなども該当します。
これは、ユーザーに対してより安定したサービス提供を行えるようにするためです。例えば、ビジネスサポート以上に加入すると、障害時により迅速なサポートケースへの返信、お客様の事例に即したアーキテクチャガイダンスの提供、AWS Trusted Advisor の全てのチェックが利用可能といったサポートが得られます。本番環境のワークロードを稼働させているアカウントではビジネスサポート、またはビジネスクリティカルなワークロードではさらに上位のエンタープライズサポートにご加入いただくことを推奨しています。
各サポートプランの比較についてはこちらをご覧ください。
AWS Well-Architected Review
FTR を受けていただく前準備として、直近で実施した AWS Well-Architected Framework のレビュー結果をご提出いただいています。こちらは、運用上の優秀性、セキュリティ、信頼性、パフォーマンス効率、コスト最適化という５つの柱に沿って、お客様のワークロードの状態を評価し、AWS が推奨するベストプラクティスに向けて改善の計画を立てていくための仕組みになります。また、こちらのレビューには、特定のドメインに特化した追加の評価を行うレンズというものがいくつか用意されていて、FTR に特化した FTR レンズも受けていただく必要がありますので、併せてご実施ください。
FTR Lens にチェックを入れる
Well-Architected レビューは AWS のマネジメントコンソールから利用できる AWS Well-Architected Tool に回答を入力していく形で進めます。全ての質問に回答を入力した後に、PDFとしてレポートを出力してレビュー前日までに弊社のレビュー担当にメールにてご送付いただく必要があります。
Well-Architected レビューはセルフチェックでも行えますが、より理解を深めるために担当ソリューションアーキテクトと一緒に進めていくことをおすすめします。もし担当がいなければ、AWS が認定した豊富な知識と経験を持つ Well-Architected パートナー にご依頼いただくのも一つの方法です。
FTR の要件としては、こちらのレビューを少なくとも年に一回、定期的に実施する計画を組織内で立てていただくことが必要になります。「８月の第一営業日に行う」といった粒度でスケジュールを設定し、形骸化せずに忘れずに実施されるような運用ルールを定義してください。なぜ定期的に行う必要があるのかというと、アーキテクチャや技術は常に進化を続けていくからです。新機能の開発や運用保守を続けていく中で、利用する AWS のサービスが増えたり、ユーザー数の増加に伴ってパフォーマンスが劣化したりということはよくあります。また、技術の進歩や AWS が日々お客様を支援する中で得られた経験とともに、「何がベストプラクティスか」というのも変化していきます。Well-Architected Framework も不定期にアップデートされ項目の追加や削除が行われるので、たとえシステム構成が変わっていなくても定期的に見直しを行うことは重要です。もしプロジェクトに新しいメンバーがいれば、システム全体の状態を把握する機会としてご活用いただくのもよいかもしれません。
AWS Root Account
AWS のルートユーザーの取り扱いに関する項目が複数含まれています。ルートユーザーはその AWS アカウントに対する全ての操作が行える非常に強力な権限を持っています。アカウントを解約して削除するようなこともできてしまうため、取り扱いには注意が必要です。
具体的にはそもそも使用しないことをおすすめします。個人ごとに IAM ユーザーを発行して必要な権限を割り当てる運用にしましょう。ルートユーザーの利用は、サポートプランを変更するなどルートユーザーでしか行えない操作に限定します。また、アカウントの侵害を防ぐために多要素認証 (MFA) の設定、ルートユーザーのアクセスキーの削除を行ってください。
そして、万が一ルートユーザーにアクセスすることができなくなった場合に備えて、ランブック (手順書)を用意してください。何者かに侵害されてパスワードを変更されてしまった、MFA デバイスを紛失または壊してしまったなどいくつかシナリオはありますが、こういった場合どのような対応をとればよいかご存知でしょうか？実際にこのようなケースが発生した場合、事態は急を要します。一刻も早くアカウントの回復を行い被害を最小限に抑えるためには、何を行えばよいかが明確で素早く作業が行える体制を作っておく必要があります。そのために、あらかじめ手順が記載されたランブックを用意し、少なくとも一度リハーサルを行っていただくことを推奨しています。
Communications from AWS
AWS アカウントの代替の連絡先を設定しましょう。こちらはアカウントの連絡先しか設定していないというお客様も多いのではないでしょうか。
様々なタイミングで AWS はお客様に通知を行いますが、こちらの代替の連絡先を設定すると、それぞれの役割に応じた通知を受け取ることができます。見逃しがちなポイントですが、代替の連絡先（請求、オペレーション、セキュリティ）を設定しておくと普段の運用が効率的になる場合があります。例えば、請求の連絡先として経理のメールアドレスを設定しておくことで、これまで毎回 AWS アカウントの管理者からメールを転送していた手間をなくすことができるでしょう。
登録するメールアドレスは担当者個人宛でも構いませんが、メールを見逃したり休暇中に緊急で対応が必要なものが届くといったリスクを避けるために、メーリングリストを使用するのがおすすめです。また、言わずもがなですがプライベートで使用している個人のメールアドレスではなく、会社から提供されているドメインのアドレスを使用しましょう。退職した後も連絡が届き続けるといった事態を避けるためです。
CloudTrail
AWS CloudTrail の設定に関する要件です。CloudTrail とは、ガバナンス、コンプライアンス、運用監査、リスク監査を行うためのサービスで、マネジメントコンソールへのログインや、 リソースの作成/削除など AWS アカウントで行われた操作履歴を記録します。これは、何か見覚えのないアクティビティが検出された際の調査に役立ちます。CloudTrail のログを追跡することで、誰がいつどのリソースにどのような変更を加えたのかを特定することができます。また、他のサービスと組み合わせることで、組織内で承認されていない特定の操作が行われた際に検知、管理者への通知、復旧アクションなどを自動で行うような仕組みも構築可能です。
AWS ではこの CloudTrail を全てのリージョンで有効化することを強く推奨しています。まずは最低限ログを取っておかなければ、重大なインシデントが発生した際に状況の正確な把握や調査を進めることができず、復旧作業や今後の対策に支障が出ます。普段単一のリージョンしか使っていないというお客様でも、必ず全てのリージョンで有効化するようにしてください。この普段使っていないリージョンこそ目が行き届かず、不正な操作が行われていてもなかなか気づくことのできないポイントになります。
また、CloudTrail のログの保存場所ですが、同じアカウント内に保存していると FTR の要件を満たすことができません。というのも、アカウントが侵害されたようなケースにおいては、同一アカウント内にログが保存されているとそのログが攻撃者によって削除されてしまうリスクがあるからです。せっかくログを取っていてもこれでは追跡することができないので、CloudTrail を設定しているアカウントとは別のドメインでログを保全することを推奨しています。例えば、監査用のログ集約アカウントのようなものを別途組織で管理し、そちらの Amazon S3 バケットに保存するという方法があります。
さらに安全にログを保全する仕組みとして、誤った削除を防ぐための MFA Delete やバージョニングの有効化、内容が改竄されてないことを検証するための整合性の検証の有効化なども併せて設定してください。
Identity and Access Management
AWS Identity and Access Management (IAM) の適切な管理は、AWS アカウント全体のセキュリティを向上させるための要となる非常に重要な項目です。そのため、このカテゴリには最も多くの要件が含まれています。ソリューションを構成するシステムコンポーネントだけでなく、人が使用するアイデンティティも含めて組織全体の運用を改善させるための観点も盛り込まれているため、社内の様々なステークホルダーと協力して対応していきましょう。
ルートユーザーのところでも触れましたが、基本的に普段の開発/運用業務には個人ごとに発行された IAM ユーザーを利用してください。CloudTrail のログは、操作の実行者のアイデンティティをこの IAM ユーザー単位で記録するため、複数人で一つの IAM ユーザーを共有していると実際にどのメンバーが行った操作なのか特定することができなくなります。
一般的にセキュリティを向上させるための方法として、強力なパスワードポリシーの適用と MFA の設定は、IAM においても同じく効果的です。忘れずに設定するようにしてください。また、パスワードのローテーションはしているがアクセスキーはずっと同じものを使っているというケースも少なからず見受けられます。アクセスキーも同様に９０日を目安にローテーションする運用を行いましょう。あるいは、システムでアクセスキーを利用している箇所は IAM ロールで置き換えられる可能性が高いです。IAM ロールでは短期間で期限が切れる一時的な認証情報を使用するため、誤って認証情報が漏洩した場合のリスクを最小限に抑えることができます。システム全体でなるべくアクセスキーを使わない設計を試みてください。
各アイデンティティに対して付与するアクセス権限に関しては、最小権限の原則に従って設計してください。実際に使用するサービス、アクション、リソースなどをしっかりと絞り込み、不要に大きな権限が付与されないように注意します。全員に AdministratorAccess や PowerUserAccess のような強力な権限を与えずに、社内でのロール、タスクごとに適切な IAM グループを作成して集中的に管理すると見通しも良くなります。
また、付与されている権限の見直しを定期的かつライフサイクルにおける重要なイベントが発生した際に実施してください。具体的には、メンバーが退職または異動になった際に、アイデンティティの削除やポリシーの変更を定められた運用に従って忘れずに行います。加えて、実施の漏れがないか、ポリシーが現状を反映した最適なものになっているかを確認する定期的な棚卸し作業も必要になります。こちらは FTR の要件としては少なくとも四半期ごとに実施する計画を定めていただくことが求められます。
次にアプリケーション観点の要件になりますが、IAM のアクセスキーやデータベースパスワードなどのシークレットをコードに埋め込むいわゆるハードコーティングは避けてください。このようなシークレットを安全に保存するためのサービスとして、AWS では AWS Secrets Manager や AWS Systems Manager のパラメータストアの機能をご活用いただけます。このようなソリューションを利用してセキュアにシークレットを管理し、アプリケーションレイヤーでのセキュリティ向上に努めましょう。
最後に、エンドユーザー/顧客の認証情報の管理についてです。お客様がログイン時に使用するID、ユーザ名、メールアドレス、パスワードなどの認証情報は必ず暗号化してください。パスワードに関してはハッシュ化も必須になります。アプリケーション側で暗号化するのが難しい場合は、ディスクレベルの暗号化でも問題ありません。お使いのデータベース、ストレージサービスごとに方法は異なりますが、ビルトインの暗号化機能が備わっているものも多いので、詳細は各サービスのドキュメントをご確認ください。
Backups and Recovery
セキュリティに関する要件が続きましたが、ここから少し信頼性、運用面での話に移ります。このカテゴリには、バックアップの取得とリストアの検証の2つの項目が含まれます。
次のディザスタリカバリ (DR) にも関係しますが、まずサービスが満たすべき水準として RTO (目標復旧時間) および RPO (目標復旧時点) が定義されていないと、適切なバックアップ戦略を決めるのが難しくなります。サービスの性質、機能、データの種類、障害時の影響度などのビジネス要件から総合的に判断して、最初に決めておくことをおすすめします。
そして定められた RPO に従って定期的に自動でバックアップを取得する仕組みを構成してください。この定期的がどれくらいの頻度が適切なのかはお客様のビジネス要件によって異なるため、サービスが満たすべき水準とビジネス要件を改めて見直し、それをシステムの運用に落とし込んでみるのが良いでしょう。場合によっては、ロストしても問題ない重要ではないデータ、後から作り直すことができるデータなどはバックアップを取らないという意思決定が正解かもしれません。
バックアップについて検討が済んだら次はリストアです。バックアップをしっかり取っていてもそれが戻せなければ意味がありません。必ずリストアの検証を行いましょう。本番同様の検証環境などを用意して、できれば同じ程度のデータ量でテストしてみるのがおすすめです。その作業時間が実際に本番でリストアを行うときの目安になります。FTR の要件としては、定期的かつ大きなアーキテクチャ変更などがあった際にテストを行う運用計画を定義していただきます。定期的にリハーサルを行うことによって、本番作業時に迷いなく、ミスなく、素早く作業を行うことができるようになります。新しく入ってきたメンバーの育成という観点も重要です。作業に携わる全てのメンバーを適切に巻き込んでいきましょう。
Disaster Recovery
続いてディザスタリカバリ (DR) です。DR もお客様によってそのスコープは様々ですが、各社のビジネス要件に沿った DR 対策をご準備ください。アベイラビリティゾーンの一つに障害が発生したケースを想定してマルチ AZ 構成を組んでいるお客様もいれば、リージョン全体の障害も想定してマルチリージョンで Active-Standby 構成を用意しているお客様もいらっしゃるかと思います。まずは貴社にとってのディザスタの定義は何か、どこまで備えるのかといった点をご検討ください。
備えるべきスコープが決まったら、それに対して有効な DR 構成を設計し、RTO および RPO を定めます。これは必ずしもエンドユーザーに対して公開している情報である必要はなく、組織内部の目標値でも構いません。RPO については前節のバックアップの頻度によって自ずと決まってくるかと思います。RTO は必ず２４時間以内に設定してください。これを超える場合は FTR の要件を満たすことができなくなります。
最後に DR のテストです。想定したディザスタが実際に発生したと仮定して、サーバーの切り替えやデータのリストアなど必要な作業を実施します。サービスが復旧するまでの時間を計測し、復旧したデータの内容を確認して、ともに RTO と RPO を満たせているか評価しましょう。もし目標を満たせていなければ、構成や目標値の見直しが必要になります。この検証をリストアの時と同じく、定期的かつ大きなアーキテクチャ変更の際に行う運用計画を定めてください。
Amazon S3 Bucket Access
S3 バケットのセキュリティについてです。S3 バケットのアクセス制限には大きく分けて2つのパターンがあります。インターネットから誰でもアクセスすることができるパブリックと、特定のネットワーク内または許可されたアイデンティティからのみ利用可能なプライベートです。FTR では意図しないパブリックアクセスが許可された状態を防ぐための取り組みが求められます。
まずは各バケットがパブリックアクセスが必要なのかそうでないのかを整理しましょう。ユーザーからアクセスできるようにしたいといった要件がある場合は、Amazon CloudFront 経由で配信する構成がおすすめです。この方法ではレスポンスの高速化など様々なメリットを受けられますが、オリジンアクセスアイデンティティを使用してアクセスを制限することで、バケット自体をプライベートに保つことができます。パブリックアクセスが必要なケースというのはそこまで多くはないはずなので、これを機に自社の構成を見直してみるのも良いでしょう。
パブリックアクセスが必要ないバケットには必ずブロックパブリックアクセスを有効化してください。こちらを設定しておくことで、意図せぬオブジェクトの公開を防止できます。
また、何らかの理由でアクセスポリシーが変更されパブリックアクセスが可能になってしまうようなことも可能性として考えられますが、それを検知できるようにしておきましょう。これを見逃すとデータの漏洩や、悪意のあるユーザーによるデータの改竄、フィッシングサイト、マルウェアの埋め込みといったインシデントにつながる恐れがあります。気づけないまま数ヶ月経ってしまうというようなことが一番怖いので、最低限のモニタリングとアラートを実装してください。AWS Config による実現方法などがブログで紹介されているのでぜひ参考にしてみてください。
Cross-Account Access
このカテゴリは、エンドユーザーの AWS アカウントに対してアクセスすることがあるソリューションの場合のみ適用される要件になります。そのような挙動がない場合は読み飛ばしていただいて構いません。
チェック観点はクレデンシャルの受け渡し方法です。まず最初に思いつくのは、エンドユーザーからアクセスキーとシークレットキーを教えてもらいそれをシステムで使用するという方法かもしれませんが、これにはクレデンシャルのローテーション、認可されていない第三者による不正利用など様々な問題が伴います。詳しくはこちらのブログをお読みいただきたいのですが、代わりに IAM ロールを用いたクロスアカウントアクセスの仕組みを構築してください。簡単に流れを説明すると、エンドユーザーのアカウントで必要な権限を付与した IAM ロールを作成し、サービス提供側のアカウントに AssumeRole を許可する形になります。
この方法であればクレデンシャルを直接やり取りする必要もなく、セキュアにアカウント間の権限委譲を行うことができます。エンドユーザー側の作業が必要になりますので、どのようなことを行えばよいのか手順を記載したガイド、または作業を自動化した AWS CloudFormation テンプレートなどをご提供ください。
FTR の要件としては、ロールの設定方法について注意すべきところがあります。AssumeRole には 外部 ID を必須とします。これは Confued deputy problem と呼ばれる、意図しない第三者によるアクセスを防ぐための仕組みです。必ず事業者側から提供された読み取り専用の一意の外部 ID を使用するようにしてください。
Sensitive Data
機密データの取り扱いに関する要件です。機密データとは何でしょうか？これもお客様によって解釈が異なる概念です。ワークロードの性質に応じて、何を機密データとして特に保護する必要があるか、データのクラス分けを行いましょう。一般的には個人情報 (PII)、保護医療情報 (PHI) などが該当しますが、その詳細な定義も会社によって多種多様です。
クラス分けができたら、機密データに対して適切な保護を検討します。保存時および転送時の暗号化を必ず行ってください。転送に関しては、外部との通信は暗号化プロトコルの使用が必須で、Amazon VPC 内部の通信に関しては必要に応じて使用を検討します。
監査も実施しましょう。誰がいつどの機密データにアクセスしたかロギング、モニタリングし、不正なアクセスが発生していないかチェックします。アプリケーションレベルでのロギングが必要なケースもあれば、AWS サービスの機能で実現できるものもあります。機密データにアクセスする経路全てで包括的なロギングが必要な点にはご注意ください。アプリケーションからデータベースに対するアクセスは監視していても、データベースに直接アクセスすることのできる経路がある場合はそちらの対応も必要になってきます。
Protected Health Information
こちらは 保護医療情報 (PHI) を取り扱うワークロードで、米国の HIPAA（Health Insurance Portability and Accountability Act) コンプライアンスに準拠する必要のある場合にレビューが必要な要件になります。
本ブログをご覧の日本のお客様にとってはほとんどの場合対象外となる項目かと思いますのでこちらの解説はスキップさせていただきます。
Regulatory Compliance Validation Process
最後にコンプライアンスに関する要件です。サービス提供のために何らかのコンプライアンス、業界標準を取得する必要のあるワークロードにおいては、そちらを遵守するための内部プロセスの定義が求められます。例えば PCI DSS、FedRAMP、HIPAA などが代表的なものですが、特に取得が義務づけられているようなものがなければレビューは不要となります。
まとめ
非常に多くの多岐にわたるチェック観点があったのではないでしょうか？ただ裏を返せば、FTR を通過したソリューションまたは製品は、これらの要件を全て満たした AWS お墨付きのワークロードだということです。セキュリティ、信頼性、運用上の優秀性に関する多くのベストプラクティスを取り入れたお客様が安心して利用できるワークロードという点を製品の付加価値として、プロモーションなどにもご活用いただけるのではないかと思います。そうでなくとも、ここでご紹介したベストプラクティスに準拠することはアーキテクチャや運用体制の改善という観点で全てのお客様にとってメリットのあるものですので、ぜひ社内でも一度レビューをしてディスカッションの機会などにご活用いただければ幸いです。FTR を受けておくべき理由や実際のレビューの雰囲気などを知れるインタビュー記事も公開しておりますのでこちらもぜひご覧ください。
【参考情報】
レビューの申請はパートナーセントラルから行えます。