Slide 1
Slide 1 text
AWS Foundational Technical Review
と向き合って得られたもの
@AWS Startup Community Conference 2022
© VALUES, Inc.
Template: https://template-parks.com/
Slide 2
Slide 2 text
このセッションには以下の情報があります／ありません
◯ FTR通過のための参考情報
➢ 体験談
➢ 対応しなければいけないこと
➢ 得られるメリット
✕ 各AWSサービス単位の詳細な技術情報
注）2021.8に受診したFTRの体験に基づいています。
現在は内容が異なる場合があります。
Slide 3
Slide 3 text
厚地 暁 (あつち あきら） from
○ マーケティングとITの会社
○ 2009～14期目
○ エンジニアは14人/122人
○ 文系卒、2001新卒でSIer、2012現職
○ 執行役員CTO
○ 2歳6歳娘の父
○ ドラムをたたく（ほぼジャズ）
Slide 4
Slide 4 text
9月にトロントの ESOMAR Congress に出ます
（世界最大級のマーケティングリサーチカンファレンス）
Slide 5
Slide 5 text
https://www.valuesccg.com/dockpit/
○ 「競合も、業界も、トレンドもわかる、
マーケターのためのリサーチエンジン」
○ 約250万ユーザのWeb行動データ
+ ビッグデータ処理技術
+ 分析技術
+ 可視化技術
○ 約350社のご契約（有料）
○ Free版もあります
○ スタートアップ向け限定プランも予定
Slide 6
Slide 6 text
AWS Foundational Technical Review
（以下FTR）とは
Slide 7
Slide 7 text
FTRとは
https://aws.amazon.com/jp/partners/foundational-technical-review/
○ APNソフトウェアパスでの評価
○ 要はベスプラ追求チェック機構
○ セルフチェック＋対面レビュー
○ セキュリティ・信頼性・ガバナンスに重点
○ ごほうびがたくさん
Slide 8
Slide 8 text
FTR通過のごほうび
○ チェック＆改善による品質向上
○ 認定ソフトウェア (AWS Qualified Software)
○ ファンディング
➢ マーケティングデベロップメントファンド(MDF)
➢ ほかにも
注）ファンド可否や適用額はいろいろなパラメータがあるようなので
くわしくはAPN担当者の方にご相談ください
Slide 9
Slide 9 text
興味わいた？
Slide 10
Slide 10 text
レビューにむけて
Slide 11
Slide 11 text
レビューに至る経緯
○ 2020年に折角テクノロジーパートナーに
なったのにリセットされて悔しい
○ ちょうど社内でもAWS最適化の取り組み
○ 主力サービスとして純粋に品質あげたい
○ パートナーシナジーほしい（前述）
Slide 12
Slide 12 text
○ お世辞にもモダンとはいえない
○ 典型的な継ぎ足しシステム
➢ 2011年～
➢ EC2多用
➢ シングルAWSアカウント
○ SWでなんとかしちゃう風潮
○ さすがにこのままではマズイと感
じるタイミング
既存システムアーキテクチャ
Slide 13
Slide 13 text
いざ、レビュー（当時のすすめかた）
○ セルフチェック (Well-Architectedツール)
○ ウォークスルー（事前レビュー的な）
○ FTR申込み
➢ チェック結果や構成図等を送付
○ レビュー！
➢ Amazon Chime、日本語、複数人可
➢ 約50項目、90分程度
Slide 14
Slide 14 text
ぼっこぼこ（泣）
Slide 15
Slide 15 text
ここからが本当のたたかい
○ こうなることは折り込み済み
➢ セルフチェックで把握
➢ 諸事情で実施を急ぐ必要があった
○ 指摘の改善には6ヶ月の猶予
➢ 半年かけてつぶしていくたたかい
Slide 16
Slide 16 text
レビューの中身と改善
Slide 17
Slide 17 text
FTR Requirements
○ 英語翻訳なので解釈が難しい場合も
○ ツールのFTR Lensと完全一致ではない
○ 抽象度／具体度や規模感も大小さまざま
○ 難しさの性質が分かれる
➢ 具体的なものは実装上の難易度
➢ 抽象的なものは相応の論拠が必要
Slide 18
Slide 18 text
こういうライトなものもありますの例
○ ルートユーザーのメールアドレスを含むアカウントの連絡先情報
を、会社が所有するメールアドレスと電話番号に設定すべし。
➢ 元からそうだし、変えるにしてもあまりシステム影響ない
○ 機密データを送信するときは、暗号化付きのプロトコルのみを使用
すべし。
➢ さすがに普通に構築していればそうなるのでは
（まして機密データ）
Slide 19
Slide 19 text
こういうヘビーなものもありますの例
○ 災害復旧の実装をテストして、実装を検証すべし。DRへのフェイル
オーバーをテストして、RTOとRPO（目標復旧時点）が定期的にお
よびメジャーアップデート後に満たされていることを確認すべし。
➢ AZ障害等を想定したDRテストを実施
➢ 事前検証レベルはやることが多いが、RTO/RPOの確認をするに
はほぼ本番どおりの環境が必要
Slide 20
Slide 20 text
意外とこういうものは無い／薄い（当時）
○ 機能要件側のアーキテクチャ自体の妥当性、効率性
➢ EC2ならべて力技な感じでもそれ自体は問題ない
➢ 総じて「統制されているか」は問われる
○ セキュリティチェックシートの類にありがちなもの
➢ FW、ウィルス対策、攻撃対策
➢ （MFA、パスワードポリシーはある）
○ 性能関連
○ コスト関連
Slide 21
Slide 21 text
改善したこと
Slide 22
Slide 22 text
通過のための主な実装改善点
○ AWS Org設定、マストなアカウント分割
➢ 監査ログ保存
○ S3, RDSの暗号化
○ システム用途アクセスキーの撤廃
○ 認証情報のSecretsManager移行
○ DRテスト環境構築とテスト実施
Slide 23
Slide 23 text
並行して行ったもの
○ ベスプラにそったアカウント分割
➢ ControlTower 等での統合管理
➢ 個人サンドボックス環境
○ SSO (Googleアカウント->AWS)
○ SessionManager移行
Slide 24
Slide 24 text
それぞれの詳細
対応してメリット得られたポイント
Slide 25
Slide 25 text
改善）アカウント分割
何でも入ってる
闇アカウント
○ CloudTrailのログ切り出しはFTRでもマスト
○ その他ベスプラに沿って構築、ControlTower、AWS Config等で統合管理
○ 強権限かつ最小権限で管理がシンプルに。クオータ抵触の回避
○ サンドボックス環境の提供で一気に検証ハードルを低下
Audit LogArchive
orgadmin
user-a user-b user-c
dev-a dev-b dev-c
prd-a prd-b prd-c
core
sandbox
develop
product
AWS Organizations
Slide 26
Slide 26 text
改善）IAM Identity Center適用（旧AWS SSO）
○ アカウント単位でのIAM認証→SSOで一括管理+Google認証と連携
➢ Googleアカウントで強制MFAのためそこに寄せる
○ もうとにかく快適
○ できるだけデフォルトの許可セットでコントロールできるように
IAM User IAM Role
IAM Identity Center
user-a
dev-b
prd-b
orgadmin
console console
user-a
dev-b
prd-b
orgadmin
Slide 27
Slide 27 text
改善）S3, RDS暗号化
○ 設定から「暗号化を有効」。キーは問わない。
○ RDSは運用中に変えるのはかなり厳しい（厳しかった）
○ S3はデフォルトだけでなく、既存の中身について別途対応
○ S3はデフォルト（のデフォルト）無効、RDSはデフォルト有効
Slide 28
Slide 28 text
改善）システム用途アクセスキーの撤廃
○ アクセスキーを使ってはならないわけではないが、
「ローテーション」が必要とされる
➢ 事実上システム用途では使えない
○ すべてロールへ
○ CloudTrailのログを見ては、利用箇所をつぶしていく。。。
○ 万が一の漏洩、に対して強固に
Slide 29
Slide 29 text
改善）SessionManager移行
○ SessionManagerの利用自体はマストではないが、「適切なログの取得と管
理」を実現する上で望ましい。
○ ログ管理、SSO連携（合わせてMFA）、VPN+bastionからの脱却
○ 初学者への導入コストも激減
VPN
bastion
servers servers
Session Manager
Terminal Browser
Slide 30
Slide 30 text
改善）認証情報のSecretsManager移行
○ 各サービスの認証情報をコードに含めない／専用サービスを用いる
➢ コードからの除外は問題無いが、設定ファイル系が厳しい
○ 地味に手こずったのがTomcat -> MySQLの認証情報
➢ コネクションプールを使うために、通常は設定ファイルに直接記載
➢ 結局専用のDataSourceFactoryを作成
■ あまり触れてこなかったこのあたりの動作原理を理解する機会に
○ こちらも万が一の漏洩、に対して強固に
Slide 31
Slide 31 text
改善）DRテスト環境構築とテスト実施
○ 「RTO, RPOを満たすことを確認できるテスト」
➢ 単にAZ障害のノード切り替え検証ではなく、総合的なテストが必要
○ CloudFormationで疑似環境を再現
➢ 定期的にやる必要があるため
➢ 復旧時間の検証が目的だと、RDS等のデータサイズも重要
➢ 実際のテストよりも環境構築に何倍もかかった
○ 実際確認できた安心感＋いつでもテストできる安心感
Slide 32
Slide 32 text
たたかいの末、、、
通過！（泣）
Slide 33
Slide 33 text
得られたもの
Slide 34
Slide 34 text
得られたもの
○ 改善によって得られた品質・運用改善
➢ 前述の のとおり
○ 箔
➢ バッジ（ちょっとシンプル、、）
○ MDF（FTR以外にも条件はある）
○ 「向き合って」得られた知見・自信
Slide 35
Slide 35 text
MDF (Marketing Development Funds)
○ （弊社の場合）
○ AWSパートナー向け資金提供プログラムのひとつ
➢ FTR通過 → APNソフトウェアパスにて「認定ソフトウェア」となり適用
○ 「マーケティングコンシェルジュサービス」
➢ 対象ソフトウェアの販促活動についての相談／支援窓口
○ マーケティングプランを作成→その活動を行うための資金援助
➢ 割とあらゆる販促活動で適用可能
Slide 36
Slide 36 text
「向き合って」得られた知見・自信
○ システムはどのような品質上の観点を持つべきか、そしてその観点のため
にどのような具体解があるのかを理解できた
➢ 永続的な鍵文字列を持たないためにロールやSecretsManagerがある
➢ 適切な権限付与のためにアカウントを分割する
➢ SessionManagerは適切なログ管理のためでもある
○ これらは、単にFTRを「通過する」だけでなく、きちんと「向き合う」こと
で得られる
➢ 単に手法のみに従うだけではもったいない
➢ AWSに限らず汎用的なベストプラクティスとして昇華できる
○ （結果、担当者はその後SAP、SCSを取得できました）
Slide 37
Slide 37 text
これからの方につたえたいこと
○ 通過だけを目指さず、きちんと向き合ってほしい
➢ FTRと、だけでなく、自分たちのシステムと、でもあります。
➢ このような儀式をきっかけに使わないとなかなか取り組めない内容。
○ といいつつ、とりあえず受けておくとよいです
➢ FTR設問項目自体にも改善の余地は多いように思います。
➢ 受診が増えるとフィードバックも増え、FTR自体の品質があがると思います。
○ あとから対応がしんどいやつに気をつけましょう
➢ S3/RDSの暗号化、ロール徹底、ログの統制（CloudTrail, SessionManager等）
➢ DRテスト対策。環境構築をCloudFormationでやるとよさげ。
○ 「必要条件」であり「十分条件」ではない
➢ 問われない観点も多い
Slide 38
Slide 38 text
Thanks!!
@accakr
https://www.facebook.com/acclegato
Contact me!
https://meety.net/matches/IkJnFtIEsMjG
もちろん
エンジニアさん
募集中
Slide 39
Slide 39 text
FAQ
○ いちばんしんどかった項目は
➢ 作業量的にはDR対応、サービス影響はRDS暗号化、難易度的にはSecretsManager対応
○ 今後の課題は
➢ 機能要件側のベスプラ化、EC2脱却、インシデント管理の効率化、などなど、、、
○ 反省点
➢ 観点はSIerの知見を使えるが、実装はAWSのお作法にきちんと従うべき。力技するな。