AWS JAPAN APN ブログ
パートナーに聞く！FTR 通過の対応のコツとは？
「AWS ファンデーショナルテクニカルレビュー (FTR) を受けてサービスの品質を高めたい！アーキテクチャを改善したい！でもどこから手をつければいいんだろう…？」そういった疑問をお持ちの AWS パートナーは少なくないかと思います。求められる要件や考え方については以前こちらのブログで解説をさせていただきましたが、実際に受けていただいたパートナーの生の声も気になるところです。
今回は、国内で初めて複数の製品（COMPANY®︎ と MKS）で FTR を通過された 株式会社Works Human Intelligence にインタビューを行い、具体的な項目のレベルまで掘り下げて技術的な難易度や対応のプラクティスについて語っていただきました。
インタビュアーは AWS パートナーソリューションアーキテクトの櫻谷が、そして Works Human Intelligence からは以下の方々にご参加いただきました。
- Product Div. SRE Dept. 所属
- 加藤文章 氏 / Senior Manager
- 片山僚 氏 / Team Leader
- 古梅麻里子 氏 / Team Leader
- Product Div. Tech Lead Dept. Bot Service & MKS Ops Grp. 所属
- 吉田治史 氏 / Grp Manager
- 兒玉拓也 氏
- 齋藤康生 氏
AWS 櫻谷（以下略）：FTR 通過おめでとうございます。複数の製品で通過されたパートナーは国内初となりますが、まずはそれぞれどういったサービスか教えてください。
COMPANY®︎ Web Service
加藤氏：大手企業向け人事システム「COMPANY®︎」は、現在合計約1200法人グループのお客様にお使いいただいている大手法人向け統合人事システムです。経営戦略の実現に必要不可欠な人材管理プラットフォームとしての機能、それから入社から退職までの労務管理を一貫して扱う機能を備え、業務の効率化や自動化をサポートしています。
吉田氏：「My Number Keeping System (MKS) 」とはクラウドサービス上で各企業の従業員、およびその家族のマイナンバーを一括で管理するマイナンバー管理プラットフォームとなります。
最初にレビューを通過したのは MKS の方ですが、なぜ FTR を受けようと思われたのでしょうか？
吉田氏：AWS のソリューションアーキテクトの方に直接見てもらって、改善方法などを一緒にディスカッションしながら進められるという点が良いと思って受けてみました。また、ソリューションの性質上、厳しいセキュリティ要件が必要になるので、そのあたりをチェックしてほしいという思いもありました。
FTR を受けられる以前にも、こういった包括的なレビューの機会はありましたか？
MKSによる堅牢な番号管理機能
吉田氏：包括的という観点だとあまりなかったと思います。どちらかというと質問ベースで、何か困ったことがあったときに AWS の方に相談させていただくようなことが多かったですね。サービスのローンチが2015年なのですが、そこで一度包括的にチェックをして、その後は FTR までまとまったレビューの機会は特にありませんでした。
では COMPANY®︎ の方はいかがでしょうか？先に MKS でレビューを受けてみて効果があったので、こちらでも試してみようという形で受けられたのでしょうか？
加藤氏：そうですね、MKS の方で受けたのが結構良かったという話を聞いていたので、一度こちらでも受けてみたかったというのと、COMPANY®︎ に関しては、どちらかというとアーキテクチャよりも運用統制まわりの整備をしたかったというのがあります。FTR には運用に関する項目が多いなと思っていて、すでに対応できているものもあれば工数の問題から後回しにしていたものもあったので、これを機会に一括で対応しようということで受けました。
ありがとうございます。アーキテクチャ面だけでなく運用統制も含めて包括的なチェックリストがまとまっている FTR はまさにピッタリかと思います。パートナープログラムという観点ではいかがでしょうか？FTR を通過することによって利用できるようになるプログラムもありますが、そういった部分もレビュー取り組むためのモチベーションになりましたか？
加藤氏：そこもかなり大きかったです。このサービスでは AWS PrivateLink をサポートしているのですが、AWS サービスレディプログラム (SRP) の認定を取得するためにはまず FTR を通過していることが必要だったので、根底には SRP 取得という目標がありました。
吉田氏：MKS も似たようなところがあって、今はプログラムが変わっていますが当時テクノロジーパートナーのティアを上げるためにはこのレビューを通過している必要があり、上位ティアのベネフィットを受けるために通過を目指していたところがあります。
なるほど、FTR にとどまらずその先のプログラムの活用も目指されていたんですね。実際に受けてみていかがでしたか。FTR を通じて得られた効果や、受ける前の期待と実際に受けてみてのギャップなどがあればお聞かせください
加藤氏：実際にチェックされる内容については、ちゃんとやるべきだよねという納得感のある具体的な項目が多いなと感じました。それらに実際に対応していくところでは、AWS の方からアドバイスをもらい相談しながらやっていけたので安心感がありました。レビューを通過したらバッジももらえますが、まさにこういった部分が AWS からお墨付きをもらえるということなんだなと感じています。よくお客様から「御社のセキュリティは大丈夫ですか？」とか「運用統制はしっかりやられていますか？」と聞かれるんですが、その時に ISO を取得していますといったことに加えて、FTR を通過していますと言えるのではないかなと思っています。
そういった営業活動にもご活用いただけるのはとても嬉しいです。日本での取り組みはまだ始まったばかりなので、エンドユーザー様にも認知していただけるようにわれわれも FTR をさらに広めていきたいと思っています！MKS についてはいかがでしょうか？
吉田 治史 氏
吉田氏：受ける前の期待という点では、どういう項目が並んでいるのか最初は知らなかったので、アーキテクチャの改善ができるんだなくらいにしか思っていなかったです。ただ、実際に受けてみると具体的な項目、例えばアクセスキーのローテーションをしなければいけないとか、必ずやらなければいけないものが一つ一つ並んでいるなと思いました。サービス開始から結構時間が経っていることもあり、古くなっている部分や、変えたいと思っていても後回しにしていた部分が洗い出されて、そういったものをまとめて対応できる良いタイミングになったかなと思っています。サービスとしては正しく動いているので変えなくてもいいけれど改善したいと思っているようなものは、きっかけがないと進めづらいですよね。それが FTR を機に解消できたのは大きかったです。
対応が難しい、または分かりづらい項目などはありましたか？
吉田氏：個別の項目で言うと、SDAT-004 の機密データのアクセスログを取得するところが難しかったです。MKS でレビューを受けた当時は、AWS CloudTrail に Amazon DynamoDB のアイテムレベルのロギングの機能がなかったんですよね。それでアプリケーション側でログを記録するようにしてたんですけど、マネージドサービスとして提供されているともっと楽だったかなと思います。
加藤氏：納得感がない項目はあまりなかったですね。当たり前にやるべきだよねという項目が多かった印象です。対応が難しかった項目で言うと、サービスの特性上 COMPANY®︎ はシングルテナント構成で AWS CloudFormation で全ての環境をそれぞれ構築しているのですが、インフラの一部の修正を適用するために全環境に対してローラーのような形で適用していくことが必要でした。あとは機密データの取り扱いというところで、データのクラス分けですね。COMPANY®︎ はテーブル数が2万、カラム数が50万くらいとかなり大規模なスキーマになっているので、それらのデータ全てに対して個人情報が含まれるかどうかを精査する作業が一番ネックになったところです。
COMPANY®︎ のアーキテクチャ
片山氏：難しかったところで言うと、新規であれば一から仕組みを作れるので良いのですが、既存のものを変えるとなると大変でしたね。これまで仕込んでいなかったログを入れるとか、既存の運用に影響を与えずに対応していくのが難しかったと思います。ただ先ほどから話に出てきているように、そこはやらなきゃいけないと前から考えていた箇所だったので、そこにメスを入れられたのは良かったと思います。
サービスが大規模であるほど既存のものの変更は大変ですよね。そういう意味では、何か今後新しくサービスを作る際には、開発当初からこの FTR の項目に沿って作っていくこともできるかと思うのですが、社内でそういった話はありますか？
加藤氏：運用統制など今回の対応で仕組み化した部分は、これから作ろうとしているサービスでも再利用していきたいと考えています。また、新しいサービスを作る際には、FTR の要件を満たしていないとリリースできないというようなプロセスを設けることを検討しています。仕組み化することで社内の工数を削減し、全てのサービスが AWS のお墨付きを得ているというような状態を作っていきたいです。第三者からレビューされるのはいい機会なので、社内リソースだけに頼り切らずにこういったものを積極的に取り入れていきたいと考えています。
リリースのプロセスに組み込むというのは素晴らしい構想ですね！すでに長く運用されているサービスの場合、新機能の開発も活発にされている中で並行して FTR の対応をするというのはなかなか大変な作業ですが、工数は確保できましたか？
加藤氏：取れましたというか、無理矢理取ってきました（笑）。FTR を通過することは優先度の高い目標でしたし、人材育成の観点でこれをやることによって対応の幅が広がるというか良い経験になるなと思っていたので。こういった社外を巻き込んだ取り組みを通じて成果をあげるというのは大きな目標の達成にもなるので、人事評価期間なども鑑みながら期日をしっかり決めてリソースは確保しました。また、AWS Identity and Access Management (IAM) の項目などでは、FTR で求めている要件よりも高いレベルですでに対応ができていたものもあったので、工数もそこまでかからなかったと思います。
適切なアクセス権限の管理、棚卸しといったあたりですよね。四半期に一度の監査など、運用ルールとして定めて必ずご実施いただく必要があり、FTR の中でも比較的ハードルが高い要件ですが、具体的にどのように対応されていますか？
古梅氏：元々社内ではずっと前から四半期に一度 IAM の棚卸し作業を行っていました。SOC1 の取得にあたって、マネージャークラスの人が確認を行う運用が行われています。
加藤 文章 氏
加藤氏：これだけでも FTR の項目に準拠できていると思うんですが、四半期に一度作業をしなくてはいけないのは面倒ですし、弊社の場合プロダクション環境の IAM を変更するには執務室から隔離されたエリアに入室して対応する必要があります。これは COVID-19 の状況下では現実的ではないので改善を行いました。どうやってるかというと、権限 (運用責任者、運用者、ReadOnly)が定義された運用者の一覧を Git で管理していて、変更が行われたら GitLab CI を介して AWS Lambda が実行され、IAM のポリシー変更や退職者の ID の削除、新入社員の追加が自動で反映されるようにしました。その実行ログと、ある時点でこの人がこういう権限を持っていましたというスナップショットを記録しておくことによって統制上の要件も満たすことができ、出社してリモートルームに入って作業を行う必要もなくなりました。現在はさらに進化させ、AWS Single Sign-On (AWS SSO) を利用することで IAM ユーザーを作成しないような仕組みに変更しています。
古梅：監査法人の対応も楽になりましたよね。今までは手作業でやっていたので本当にそれをやったのかというところはよく指摘を受けたりしていたんですが、自動化したおかげでいつどのような変更が行われたのか分かりやすくなりとても助かっています。
自動化することによって様々な面でメリットがあったんですね。他のパートナーさんも参考にできる非常に良いモデルケースかと思います。では、FTR の項目やレビュープロセスについて改善してほしい点や要望などはありますか？
兒玉氏：FTR で対応できている項目はそのまま SOC などの対応で監査法人に提出することが多いので、こういった要件に準拠しているという状態をレポートにまとめて出力する機能などがあればうれしいです。AWS の機能として出してくれれば監査法人側もフォーマットが統一されていてチェックも楽だと思うんですよね。
加藤氏：私がまず思ったのは、FTR という名前がちょっと分かりづらいところです。以前はテクニカルベースラインレビューという呼び方をされていましたよね。こちらの方が知らない人にもどういうものなのか意味が伝わりやすいんじゃないかなと。「ファンデーショナルテクニカルレビューを通過しているソリューションです！」と言っても何がすごいのかよく分からないかもしれません。あとは内容が英語なので、お客様への説明にも苦労しています。社内的には日本語訳をもらっていたので特に問題ありませんでしたが、公開されているチェックリストの日本語化もお願いしたいです。
最後に今後の取り組みについて聞かせてください
加藤氏：今回レビューを受けてみて、改めてセキュリティをもっと強化していこうという気持ちになりました。インシデントも世の中的には増えていると思いますが、しっかりと検知をして簡単に調査できる状態を作っていこうと思います。SIEM on Amazon OpenSearch Service というものもありますが、将来的にはあれを運用統制に使っていこうかなと考えているところです。あとはソリューションの中の部分ですが、Amazon EC2 インスタンスで運用している部分が多くて、そこをコンテナ化などマネージドサービスに置き換えていくようなところですね。新しい技術をどんどん採用していくことによってメンバーにも AWS を好きになってもらえるかなと考えています。
吉田氏：MKS の方ではまず AWS PrivateLink 対応を進めていこうと思っているのと、あとは FTR の中でも DR の話がありましたが、大阪リージョンができて使用できるサービスもだいぶ増えたので DR サイトとして大阪リージョンを使っていこうと思っています。
本日は貴重はお話をありがとうございました！
これから FTR を受けるにあたって、実際の対応のイメージが湧く学びの多い内容だったではないでしょうか。また、すでにレビューを受けて現在対応を進められているパートナーにとっても、IAM の権限管理・監査の仕組みなど自社で取り入れられる参考になるものもあったかと思います。サービスの品質向上、現在のアーキテクチャの状態の評価にぜひこのレビューをご活用ください！申請方法や進め方については以下の参考資料もご覧ください。
ISV パートナーパスと FTR の概要を理解するには >> APN ナビゲート – AWS ISV パートナーパス
FTR の進め方をさらに詳しく理解するには (エンジニア向け) >> AWS PartnerCast ウェビナー録画
他のインタビュー記事を読んで FTR の理解を深める >> パートナーに聞く！FTR 通過を目指すべき理由とは？【前編】
レビューに備えてチェックリストの中身を理解する >> 【Partner-Hosted 編】ファンデーショナルテクニカルレビュー (FTR)でチェックされるポイントとは？