AWS認定製品？AWSファウンデーションテクニカルレビュー【FTR】とは

みなさんこんにちわ！クッキーさんです。
急に暖かくなり、庭の植物や野菜達が急に勢いづき春を感じているおじさんです。
さて今日は、AWSのソリューション評価「FTR」について、業務で携わることがありましたので備忘録的にブログにしたいと思います。

FTRとは

正式名称「AWS Foundational Technical Review」と呼ばれ、AWS上でSaaSを提供するにあたって、AWSのベストプラクティスの沿っているかを評価する制度です。
セキュリティ、信頼性、運用上の優秀性の観点で、ワークロードを評価・診断され、認定された場合にはFTR通過済みソリューションとして公開されます。
上記以外にも、AWSよりパートナー特典として様々な恩恵を授かることが可能だそうです。

FTRの要件

FTRは複数のカテゴリから構成されており、それぞれにチェック項目が存在します。
Partner-Hostedの場合ですが、カテゴリ別で軽く説明してみたいと思います。

Support Level

ユーザーに対して安定したサービスを提供するため、サポートレベルをビジネスサポート以上へ上げる必要があります。
この項目では、以上がすべての内容となるのですが、追々出てくるCloudTrailのログ保存先のアカウントであったり、関連するアカウントはすべてビジネスサポート以上へ変更が必要です。
ここの部分で、AWS社のレビューで引っかかりました・・・。

AWS Well-Architected Review

事前準備として、マネジメントコンソールから利用できる「AWS Well-Archtected Review(W-AR)」と「FTRLens」のレポートを、レビュー前日までに提出する必要があります。
W-ARはベストプラクティスを認識するための物であり、すべての改善対応を行う必要はなく、どちらかというとFTRLensがメインになりました。
さらにいうとFTR用のSpread Sheetが存在しており、この項目が網羅されていれば、基本的には問題ありませんでした。
また、要件として1年に1回当該内容を実施する必要があり、こちらをどのタイミングで実施するかの詳細を、Spread Sheetへ記載する必要があります。

AWS Root Account

rootユーザは例外操作のみ使用する、MFAを有効化する、rootのアクセスキーは使用しない、資格情報流出時のRunbookを作成する、といった内容になります。
ここでターゲットとなるRunbookは、オートメーションドキュメントではなく、通常の運用手順書を準備しAWSへの問い合わせを含まない内容を、事前にデモで実施する必要があります。

Communications from AWS

連絡先関連の項目になり、会社のメールアドレスや電話番号を登録したり、見落としがちな代替連絡先も設定する必要があります。
また、AWS Organizationsを利用している場合は、会社管理のため対応不要で無視することも可能です。

CloudTrail

CloudTrailをすべてのリージョンで有効化したり、ログの検証有効化、バージョニング等のログ取得・保存に関する項目です。
特にネックになる部分はないのですが、ログ保存先として別アカウントに保存する必要がある「らしい」ので、S3のバケットポリシーを設定する必要があったりします。
なぜログ保存先を別アカウントにするかというと、root等の資格情報流出時にログを削除されるのを防ぐ意味合いがあります。
また、S3アカウントでもCloudTrailを有効化したり、Support Levelの項目もターゲットとなりますのでご注意ください。

Identity and Access Management

一番ボリュームが多い(と思った)項目になります。
IAMユーザのアクセスキーのローテーションや、パスワードポリシー等の運用ルール設定が大半を占めています。
また、複数のユーザで単一のIAMユーザを利用するのではなく、個人に対して割り振る項目もあります。
結局、ボリューム自体は多いですがやる内容としては、最小権限であったりの基本的な物がメインとなるので、以外と簡単でした。

Backups and Recovery

どうやってバックアップを取るのか、リストアテストは行ったか、定期的なリストアテストをいつやるか、という点になります。
また、DR部分にもかかってきますが RTO(目標復旧時間)とRPO(目標復旧時点)を決めておく必要があります。
FTRの要件的に、RPOは24(時間)以内にする必要があります。

Disaster Recovery

DRについてのスコープは、FTRの要件としては特に存在していないためマルチAZ、マルチリージョンであったり、Route53での切り替えでのDRなど自由に決められます。
ただ、RTO,RPOが要件通りになっているか、DRテストの実施や定期的なDRテストをいつやるかであったり運用部分も関わってきます。
物量は少ないので、ゴールをきちんと定めて課題をクリアしていけばすぐ完了できます。

Amazon S3 Bucket Access

この部分は、本番ワークロード上にS3が存在しなくても、CloudTrail用のS3がターゲットに含まれるのでご注意ください。
パブリックアクセス無効になってるか、ログアラートがあがるようにしてあるか、といった簡単な内容になります。
私で対応した内容としては、バケットポリシーでの制御、AWS Configでのアラート設定で実施しました。

そのほか、「Cross-Account Access」、「Sensitive Data」、「Protected Health Information」、「Regulatory Compliance Validation Process」がありますが、
E/Uアクセスがなかったり、コンプライアンス的な要件が今回のワークロードに存在しなかったので、詳しく理解しておりませんので説明できません。あしからず…。

まとめ

FTR認定に携わったのは今回が初めてでしたが、非常に難しくかつ環境理解が重要だと身に沁みました。
オンプレミスの環境しかほぼ触っていなかった自分としては、インパクトがありましたが非常に楽しい内容でした。

今回はざっくりとした内容で説明しましたが、AWS公式ブログに乗ってない内容もありますので、併せて確認してもらえると光栄です。

以上、クッキーさんでした。