はじめに
2023年10月頃ですが、私が担当しているopswitchというサービスが AWS ファンデーショナルテクニカルレビュー (FTR) に合格できましたので、苦労した点などを書き留めておきます。
AWS FTRとは
AWS FTRとはソフトウェアがAWSのベストプラクティスに沿って開発されていることをAWSに認定してもらうパートナープログラムです。
大きく分けて３つのタイプがあるのですが、opswitchが取得したのは Partner Hosted というタイプです。他のタイプは未経験なのでPartner Hosted に関して書いていきます。 Partner Hosted はAWS上に構築されているサービスが対象です。
以下の公式のブログが詳しいのでご覧ください。
【Partner-Hosted 編】ファンデーショナルテクニカルレビュー (FTR) のチェックリスト解説
チェックリストに関して
FTRに合格するためにはチェックリストの要件をすべてクリアしている必要があります。チェックリストはパートナーセントラルのFTRガイドからダウンロードできます。チェックリストのPartner Responseは日本語で書いて問題ありません。
チェックリストは更新されることがあり、いつの間にかチェックリストが古くなり無効になっていた、ということもありえますので注意しましょう。私が対応していた時は2023年の8月に新しいバージョンが出て、私が使っていたチェックシートは2023年11月まで有効と書いてありました。私は新旧を見比べて新しい方が対応しやすそうだったので新しいチェックリストに変更しました。
各項目の対応方法に関しては上記の公式ブログの解説に詳しく書かれています。最初にSecurity Hubを有効にして、暗号化されていない箇所などセキュリティの項目に対応していくとよいかと思います。 Security Hubの結果はCSVに出力して申請時に提出します。
苦労した項目
いくつか対応に苦労した項目がありましたので、行った対応方法を記載します。
アーキテクチャレビュー (WAFR-001)
AWSのブログにも書かれていましたが、アーキテクチャレビューは Well-Architected Tools を使ってレビューをしました。レポートをPDFにして提出します。結構量があるので何日かに分けて実施しました。時間はかかりましたが監視の不足している部分やパフォーマンスの目標値が設定されていないことに気づくことができました。レンズは AWS Well-Architected Framework を選択しました。以前はAWS FTR用のレンズがあったようなのですが現在はなくなっています。
AWS責任共有モデル (WAFR-002)
チェックシートには「セキュリティとレジリエンスに関する AWS 責任共有モデルを確認する。」とあります。セキュリティに関してはのどこからが自分たちの責任範囲でどのような対策をしているかをPartner Responseにまとめました。
復元力に関しても同様にどのような障害が発生した場合を想定し、どのような対策をしているかをまとめました。
インシデント計画書 (ARC-005)
インシデント計画書を書いたことがないため、個人的にはこれが一番大変でした。弊社はISOを取得しているため、会社自体のインシデント計画書があり、そちらを参考にベースを作成しました。 次にSaaSで発生するインシデントのパターンや対応方法を調べながら進めました。ケース別にインシデントへの対応は記載しましたが、そこまで網羅はしておらず数パターンです。チェックシートのExcelにシートを追加して、インシデント計画書を作成しました。
インシデントの管理にはAWS Systems Manager Incident Managerを使いました。Security Hubでアラートが上がると自動でインシデントを作成できるので便利です。
脆弱性検査 (SECOPS-001)
脆弱性評価には Inspector を利用しています。私の担当しているopswitchでは、ECSやLambda を使っているのですが、Inspectorがデプロイ時に脆弱性検査を行います。CodePipeline、CodeBuildを使ってデプロイしており、脆弱性検査でCriticalな脆弱性が見つかった場合はデプロイを中断するようにしています。
回復力テスト (RES-004)
回復力テストではAWS FISを使い意図的に障害を発生させました。ECSやRDSは対象のサービスになっていますが、Lambdaは対象外なので実施できませんでした。
AWS Fault Injection Service とは
他にもストレージにはAuroraを使っているので、Auroraで使える障害挿入クエリを使って障害を発生させています。
障害挿入クエリを使用した Amazon Aurora MySQL のテスト
障害挿入クエリを使用した Amazon Aurora PostgreSQL のテスト
AZレベルまでの障害を想定しテストしました。
審査にあたり
審査の際にはチェックリストを見る前に、サービス内容とアーキテクチャの説明が必要です。アーキテクチャ図なども事前に準備しておきます。
また、パートナーセントラルから申請時に「オファリングの説明」を記載する欄がありますが、こちらは英語でサービスの説明を記載する必要がありました。
最後に
弊社AWS事業本部の方針でFTRを取得することになったのですが、実際やってみて本当にいい経験になりました。もし次回、AWSでシステムを構築することがあれば最初からFTRを取得する前提で構築したいです。
他にもFTR取得するメリットとしては以下があります。
- AWS Partner Solutions Finder に掲載される。
- AWSバッチが使用できる。
弊社のページにopswitchが登録されています。
ぜひ挑戦してみてください！