図解 Financial Services Industry Lens (AWS Well-Architected Framework)

Financial Services Industry Lens (FSI Lens) とは?

Lens とは、AWS のベストプラクティス集である Well-Architected Framework (W-A) の拡張として、特定領域に特化したベストプラクティスをまとめたホワイトペーパーです。

2020年6月時点では、6つの領域に対する Lens が公開されています。他の5つの Lens が全てテクノロジーカットの中、FSI Lens だけが業種カットで、融業界に特化した Lens となっています。

#余談中の余談ですが、イラストは自分で書いています(最近、グラレコも勉強中...)

f:id:imiky:20200629101101p:plain

docs.aws.amazon.com

金融系以外の人は参考にならない?

FSI Lens は「セキュリティ」に非常に強いという特徴を持っており、業界によらず、知っておいて損はないナレッジが詰まっています。

W-A の構造をざっくりとおさらいしておくと、5つの柱(≒ベストプラクティスの狙い/観点)に対して、「設計原則」と「質問」がまとめられています。W-A を利用することで、ベストプラクティスを知り、自分たちのシステムに潜在しているリスク・改善点を顕在化、議論することができます。

f:id:imiky:20200629101125p:plain

 FSI Lens も W-A の拡張ですので、同じ構造をしていますが、質問の個数をカウントしてみると、通常の W-A に比して、FSI Lens はセキュリティの柱が強いことが分かります。どんな業界であろうと、セキュリティで AWS のベストプラクティスから大きく外れることはしたくないと思いますので、FSI Lens は金融系以外の方にもおすすめです。

f:id:imiky:20200629101145p:plain

※Lens はあくまで W-A の拡張ですので、まずは通常の W-A を確認、その追加項目として Lens を活用という位置づけです

なぜ、この記事を書いたか?

ホワイトペーパーは、基本的に文字ばっかりです。そして、2020年6月現在、FSI Lens は英語版しか公開されていません。

まずは、お手軽に概要レベルで把握したいという方も多かろう(私が欲しかった)と思ったので、図をベースにまとめてみようと思ったしだいです。が、私の体力の都合上、セキュリティの柱の質問に限って紹介していきます。

ようやく本題

以降、セキュリティの柱の質問を引用→私なりに図示→一言コメント、をひたすら進めていきます。セキュリティの柱の質問に限定したとはいえ、全ての観点を取り込むのは分量的に難しいので、気になった質問は原文をご確認ください。

FSISEC1: IAMロールが最小権限の原則に準拠していることをどのように保証していますか?

f:id:imiky:20200629101207p:plain

仕組み/プロセスが重要ですね。そうだ!そうだ!と言っているだけだと、しだいにやらなくなると思います。

FSISEC2: 特権アカウントの使用をどのように監視し、権限の昇格をどのように防いでいますか?

f:id:imiky:20200629101230p:plain

監査ログは専用アカウントに集めましょう。集めるだけではなく、可視化/リスクの高い操作を検知する仕組みも必要かと思います。

GuardDuty は2020年4月に Organizations サポートされました。
Amazon GuardDuty が、AWS Organizations のサポートでマルチアカウントの脅威検出を簡素化

 

f:id:imiky:20200629101303p:plain

防ぐことも大切ですが、防ぐだけではなく適切に委任する方法も考えましょう。

f:id:imiky:20200629101424p:plain

委任するために、IAMの設定変更を監査できるようにしておきましょう。

FSISEC3: IAMロールの設計の一部として、職務の分離にどのように対応していますか?

f:id:imiky:20200629101516p:plain

カスタマー管理ポリシーで権限をつける場合も、実際の業務上の役割を意識して付与すると良いかと思います。

FSISEC4: 全ての人的アクセスがフェデレーションを使用していることをどのように保証していますか?

f:id:imiky:20200629101549p:plain

AWSに限らず、IDaaSに認証を集められるといいですね。マルチアカウント環境では、AWS SSO で同様のフェデレーションアクセスが可能で、権限も一元管理できます。 

FSISEC5: 全てのサードパーティアプリケーションがベストプラクティスに従って、AWS API にアクセスしていることをどのように保証していますか?

f:id:imiky:20200629101620p:plain

 ここまでめげずに読んでいただいている方には釈迦に説法ですね。アクセスキー生成の監視・検知も有効かと思います。FSISEC1の通り、認証情報・権限の定期的な棚卸しもしましょう。 

FSISEC6: SDLC環境(dev、test、prod)間の分離をどのように確保していますか?

f:id:imiky:20200629101700p:plain

この図はマルチアカウント戦略の一例です。少なくともSDLCの環境別には分けましょう。右側の共通基盤の整備も大切ですね。

FSISEC7: トラフィックを可能な限りプライベートに留めていますか?

f:id:imiky:20200629101801p:plain

 この図はゲートウェイ型のエンドポイント(S3, DynamoDB)の話です。インターフェース型のエンドポイント(その他のVPCエンドポイント対応サービス)は、別の特徴があるので、ドキュメントをご確認ください。

インターフェイス VPC エンドポイント (AWS PrivateLink) - Amazon Virtual Private Cloud

FSISEC8: 悪意のあるトラフィックがないか、ネットワークをどのように検査していますか?

f:id:imiky:20200629101827p:plain

ここは、サードパーティを積極的に適用していった方がいいと思います。

FSISEC9: コンピュートリソースへのアクセスをどのように保護していますか? 

f:id:imiky:20200629102048p:plain

 ダルくなったわけではありません。実際にホワイトペーパーにこのような文脈の話が書かれています。特に本番環境だと、OSにログインするだけで面倒なことが色々と増えると思いますので、サーバは大切にお世話せずに使い捨てる前提で、まずは考えた方がいいと思います。

※緊急用のアクセス経路はSSMのセッションマネージャを使いましょう(インバウンドポートを開ける必要もなく、SSH鍵の管理も不要なため)とも書かれています

FSISEC10: コンピュートリソースをどのように構成し、強化していますか?

f:id:imiky:20200629102123p:plain

イメージ更新はダルいですが、更新せずに使い続けると、どんどんとセキュリティリスクが高まっていくので、EC2 Image Builder を活用して、効率的に定期更新しましょう。

f:id:imiky:20200629102203p:plain

AMIを更新するだけだと意味がないので、新しいAMIが使われていることをチェックしましょう。

残りは後編とさせてください...

あと質問が9個もあると思うと、心が折れました。後編FSICES11〜19は後日投稿します。 

前編は以上です!