AWS FTR認定への取り組み方
SecureNavi 基盤開発部の勝山です。
🎄 SecureNavi Advent Calendar 2024 🎄の一貫としてこの記事を書いています。
駆け出しエンジニアの頃にQiitaに記事を書いていたこともあったのですが、そういった発信を最近やれてないなという想い、自分はQiitaやZennに助けられてきたのに申し訳ないという想いがあった中、こういった機会をいただけたので久々に書いてみることにしました。
いろいろ書きたいことはあったのですが、年末ということでお題は「今年一番苦労したFTRについて」です。
FTRを取得しなければいけない方
FTRを取るメリットはわかった、でもどうすれば？という方
FTRってどれくらいの期間がかかるのかを知りたい方
FTR取得を会社として目指すことになった時に、私は方法も期間も何もわかっていませんでした。そんな方の参考、救いになれば幸いです。
FTRとは？
AWS Foundational Technical Review (FTR) を使用すれば、ソフトウェアまたはソリューションのリスクを特定して修正することができます。
AWSが提供する無料のレビューの枠組みです。
こちらの記事で丁寧に解説されていますので、今回は割愛します。
FTRのメリット
様々なメリットがありますが、個人的には以下の4点が大きいと感じています。
構成や運用の見直しが図れる
セキュリティリスクを逓減できる
AWSのFTR認証取得済みバッチを得て対外的に安心できる製品だとアピールすることができる
AWSが提供するパートナープログラムの参加資格となる
FTR取得までにかかった期間
Total: 9ヶ月 (3人)
[前提]
FTRに対応したエンジニアは計3名であり、他の業務にも取り組みつつ、
7割はFTR関連タスクを実施していたイメージです。
内1名はAWSに大変精通した方であり、ご尽力がなかった場合は
同じ人数でもおそらく3〜4ヶ月は追加の取り組み期間が必要だったと思われます。
[内訳]
各種チェックリスト対応で特に時間がかかったもの ベスト3
1位: SECOPS-001 脆弱性管理の実行
要件としては「継続的な脆弱性の検知の仕組みづくり、および、その対応」になりますが、やや解釈に困り、弊社では以下の実施をもって満たしていると判断しました。
外部の脆弱性診断の実行、対応 (アプリケーションの脆弱性検知・対応)
yamoryの導入、対応 (dockerイメージのバージョンやアプリで使用するライブラリの脆弱性(CVEなど)検知・対応、クラウドインフラの構成の不備や脆弱性の検知・対応)
WAFの導入
CIでの静的コード解析ツールの実行
FTRはテストではないので、明確な決まりや答えがあるわけではなく、取り組みを通しての改善が目的であるそうです。困った際は、どのように対応すべきか相談してみても良いかもしれません。
ちなみに、ライブラリの脆弱性対応のためにバージョンアップを行ったのですが、万全を期すためにE2Eテストの作成も並行して進めたため、8ヶ月ずっとこの課題に取り組んでいたような気がします。
2位: RES-004 回復力テスト
普段利用しているリージョンが完全に使用できなくなる想定での復旧テストを行い、復旧計画の策定と手順の作成を行いました。元々Terraformで構成管理がされている状態ではあったものの、 弊社のTerraformの構成が良くないためか手動で作業するポイントがいくつか発生したり、 S3の別リージョンへのレプリケーションは無事行えているか、 そもそも障害発生時に誰にいつ伝達すべきか、など確認事項が多数ありました。
序盤の山場であり、3ヶ月ほどかかりました。
3位: IAM-001 AWSにアクセスするすべてのIDの多要素認証有効化
正確には多要素認証有効化に時間がかかったわけではなく、IAM-001や002, 003を満たすべくControlTower (IAM Identity Center)の導入、および、IdPとの連携を行う作業、そして、IAM-005を満たすための適切な権限管理の設定にそれなりに時間がかかりました。
一つ一つ切り離して語れるものではないのでトータルの時間の計算は難しいですが、およそ4ヶ月から5ヶ月はかかっていると思われます。
FTRへの取り組み方
FTRではチェックリストが提供されており、基本的にはそのチェックリストを満たせばよいという考え方です。
チェックリストについては日本語対訳が用意されていますが、細かなニュアンスはオリジナルの英語表記を確認したほうが良い場合もあります。
しかし、どちらを参照しても直感的には理解できない項目や解釈に困るものも一部含まれています。
(ちなみに、取り組み後の回答は日本語でOKです)
そのため、弊社では以下の流れで取り組みました。
レビューの実施目安の設定
チェックリストの解読
チェックリストとWell Architected Frameworkの紐づけ
各課題の実施タイミングやスケジュールの決定
各課題の取り組み
レビュー実施
指摘事項修正＆確認依頼
1.レビューの実施目安の設定
大体のレビュー実施日目標を定めました。元々23年秋から冬にかけて社内で検討し始めたFTRを24年1月頃から取り組み始め、半年後にあたる24年秋から冬にかけての取得を目指しました。
2.チェックリストの解読
まずは提供されるチェックリストの解読を試みました。基本的にはチェックリストの項目をセルフレビュー(自社レビュー)し、すべて満たしている状態にしたうえで、AWSのFTR担当者の方にレビューをお願いすることにしました。
3.チェックリストとWell Architected Frameworkの紐づけ
チェックリストの中には、具体的な対応方法が見えにくいものもいくつかありました。FTRはWellArchのセキュリティの柱と関連している項目が多く、そちらを参考に具体的なTODOに落とし込みました。
4.各項目の実施タイミングやスケジュールの決定
JIRAでチケット管理(イシュー管理)をしているので、FTRの項番ごとにチケットを作成し、時間がかかりそうなもの、逆にすぐ終わりそうなものを選定し担当者をアサインしました。
とはいえFTRに精通しているメンバーはいなかったので、取り組みを開始してからチケットの細分化を行ったり、スケジュール調整を行ったものも多数でした。
5.各課題の取り組み
各チケットに、FTRで要求されている事項、関連しそうなWellArchの項目を書き起こし、担当者が対応方針を考案し、チーム内でそれをFixしました。
構成変更が必要なものについては、基本的には本番環境同等のステージング環境上で検証を進めつつ、順次本番環境への適用を行っています。
レビューの際に証跡が必要そうなものや、日頃の運用に活用すべきものについては手順書や解説のドキュメントをNotionで作成しました。
結果的に、レビューの際に提出が求められることはありませんでしたが、FTRで必要な定常作業を行う際は、作成したドキュメントが役に立っています。
6.レビュー実施
レビューは先方のご担当者の方 1名と、FTRに取り組んだ3名でAmazon Chimeにて行いました。(Amazon ChimeはGoogle MeetやZoomに近いオンラインミーティングツールです。)
チェックリストを1つずつ順に確認し、OK、 NGを判断していきます。
NG項目については、なぜNGなのかという理由をコメントいただけるので、持ち帰り修正や確認を行います。
7.指摘事項修正＆確認依頼
修正が完了したら、メールなど、文書ベースで再レビューの依頼を行います。オンラインミーティングを再び実施できないことに注意が必要です。(2024年9月時点)
NG項目がクリアされたと判断いただければ、認定取得が完了です！
終わりに
ここまでまるで私が方針やアサインを決定していたかのような書きっぷりですが、実際はAWSに精通したK.Tさんを筆頭に、相談、相互レビューや作業のチェックを行いながらなんとか目的の時期での達成に漕ぎ着けています。(大変感謝しております🙇！！！)
FTRは取得までそれなりの期間と工数を要するものですが、達成できた時には構成や運用へのある程度の自信、自身の経験や成長、何より、お客様への安心につながっていることを実感できると思います。
ぜひご覧の皆様もトライしてみてください！
次回の記事は営業部 吉木さんの記事「一人前フィールドセールスチームリーダーへの道（最初の90日間マニュアル）」です。お楽しみに！
■ご参考
■採用情報
■カジュアル面談一覧
■募集ポジション一覧