図解 Financial Services Industry Lens (AWS Well-Architected Framework) - 後編
今回のおはなし
以前、Financial Services Industry Lens（FSI Lens） を図解すると題して、セキュリティの柱から10個の質問を図解しました。残り9個が放ったらかしになっていましたので、後編として図解していきたいと思います。
FSI Lens のおさらい
Lens とは、AWS のベストプラクティス集である AWS Well-Architected Framework (W-A) の拡張として、特定領域に特化したベストプラクティスをまとめたホワイトペーパーです。「質問」を端緒にベストプラクティスを知り、自分たちのワークロードの改善点を顕在化させることができます。
2020年10月時点では、6つの領域に対する Lens が公開されています。他の5つの Lens が全てテクノロジーカットの中、FSI Lens だけが業種カットで、金融業界向けの Lens となっています。では、金融業界しか関係ないものなのかというとそういうわけではなくて、FSI Lens はセキュリティの柱が強く、セキュリティは業界問わない観点かと思いますので、広く参考になるものと考えています。
では、さっそく！
以降、前回の続き、FSISEC 11から順にひたすら図解して、ちょいコメントを繰り返していきます。
FSISEC11: コンテナリソースをどのように構成し強化していますか？
セキュリティは任せられるなら任せたいですよね。また、必ず自動化されたパイプラインからのみ、イメージをビルド・プッシュし、セキュリティチェックも仕組みとして組み込みこんでしまいましょう。
FSISEC12: 新たな脅威にどのように対応していますか？
InspectorでサーバのCVEチェックが可能です。チェックは当たり前、Lambdaで自動修復もできるよ。とさらっと書かれていますが、自動修復はイメージ付きませんでした。。。ナレッジある方は、コメントいただけるとうれしいです。
なるべく前工程で気づいた方が、開発効率としても良い（デプロイしてから気づいて修正してやり直しとなるよりは）ですし、規定のチェックを通過したものしかデプロイされないことが機械的に保証できるので、セキュリティリスクの緩和にも効果が大きいかと思います。
WAFのルールのメンテも大変ですよね... AWSが提供しているマネージドルールとMarketplaceでパートナーが提供しているマネージドルールを活用することもできます。
FSISEC12では、ワークロードは高速・高頻度に進化させ続けたい、一方で、脅威・脆弱性も新しいものがどんどん出てくるという状況においては、セキュリティチェックを自動化された仕組みとして組み込むことが重要ということを認識するための質問かと思います。
FSISEC13: データをどのように分類していますか？
規制や組織のルールで何が機密データとされているか、どこに機密データがあるかを認識するところがデータ保護のスタート地点かと思います。規制を受けるようなデータはなるべく狭い範囲に隔離できると幸せですね。
とはいえ、どこに機密データがあるかを細かく・実態に合った形で特定する、もしくは、想定外に含んでしまった場合に気づくのは、難しい面もあるかと思います。AWSにおいて、データの集約場所となるS3では、Macieというサービスで個人情報の自動検出が可能です。
Macieは2020年5月に全面的に刷新され、東京リージョンでも利用可能となっています。どのS3バケットのどのオブジェクトにどのような個人情報があるかを自動検出します。会員番号など独自のパターンを定義して、そのパターンに基づいた検出も可能です。
FSISEC14: クラウド環境でのデータ漏洩対策はどのように行っていますか？
ここは「サードパーティ製品を使え、以上」という感じですね。AWSのサービスとして、何か出ないですかね。
こちらはS3の例ですが、自社が管理するAWSアカウントのS3バケットのみ、もしくは、特定のS3バケットにしかアクセスできないような環境を構築することが可能です。
ただし、全てのAWSサービスでVPCエンドポイントが利用できるわけではなく、かつ、ほとんどのサービスはインターフェース型のVPCエンドポイント（S3とDynamoDBだけがゲートウェイ型）で、インターフェース型はサービスによって、エンドポイントポリシーを適用できるものとできないものが存在するので注意が必要です。詳しくは、ドキュメントをご確認ください。
インターフェイス VPC エンドポイント (AWS PrivateLink) - Amazon Virtual Private Cloud
S3のパブリックアクセス拒否設定やデフォルト暗号化を活用することで、リスクの緩和が可能です。SCPで設定変更を禁止する（予防的統制）のか、Configで設定を監査する（発見的統制）のかは、組織のセキュリティポリシーによるかと思います。
GuardDutyは有効化しましょう。前回、FSISEC8で記載した通り、細かくトラフィックを監視するのであれば、サードパーティ製品の導入を検討した方が良いかと思います。
FSISEC15: 暗号化キーをどのように管理していますか？
KMSの仕様・機能は必須で押さえましょう。
FSISEC16: アプリケーションの認証情報（データベース接続文字列やログイン情報など）をどのように保護していますか？
AWSでは、安全に認証情報を保管・利用できるサービスが用意されています。IAMによって、認証情報へのアクセス制限が可能です。
FSISEC17: シークレットのアクセスと使用をどのように監査していますか？
Secrets Managerは、CloudTrailと統合されているので、簡単にシークレットの変更操作や、削除予定のシークレットに対するアクセスを検出することができます。
FSISEC18: ログの完全性とセキュリティをどのように保護していますか？
監査ログを取得していても、改ざんできる状態だと意味がないので、適切に保護しましょう。
FSISEC19: ランサムウェアからどのように保護していますか？
図解と言いつつ、最後は文字ばかりになってしまいましたが、他の質問で実装してきたことが、ランサムウェア対策においても有効です。加えて、攻撃から回復するためのバックアップ取得がポイントかと思います。
おわりに
後半の方が重かったです。。。ホワイトペーパー（英語）を読むのはつらい。。。
とはいえ、FSI Lensは、本当に参考になる情報ばかりですので、この記事が実際のホワイトペーパーを読む入り口／きっかけになれば幸いです。
