【レポート】セキュリティアンチパターンから学ぶミステイクを回避する方法 #reinvent #FSV301

ご機嫌いかがでしょうか、豊崎です。

私は今、ラスベガスで開催されているre:Inventに参加しています。

以下のセッションを拝聴しましたので、レポートをさせていただきたいと思います。

セッション概要

At AWS, security is job zero. Our infrastructure is architected for the most data-sensitive, financial services companies in the world. We have worked with global enterprises to meet their respective security requirements and have learned that there are best practices and pitfalls to avoid. In this session, we provide a guided tour of governance patterns to avoid – ones that may seem logical at first, but that actually impede your ability scale and realize business agility. We also cover best practices, such as setting up key preventative and detective controls for implementing 360-degrees of security coverage, practicing DevSecOps on a massive scale, and leveraging the AWS services (such as Amazon VPC, IAM, Amazon EMR, Amazon S3, Amazon CloudWatch, and AWS Lambda) to meet the most strict and robust enterprise security requirements.

スピーカーは以下です。 ・Kurt Gray - Global Solutions Architect for Financial Services, Amazon Web Services ・Jonathan Baulch - Director, Architecture, Fidelity Investments

レポート

本セッションでは、アンチパターンから学ぶ、ベストプラクティスが紹介されました。

セキュリティアンチパターンのリスクについて

• SecOpsの俊敏性の欠如
• ビジネスの俊敏性の欠如

４つの観点からセキュリティアンチパターンが紹介されました。

• アカウント構成
• ネットワークデザイン
• セキュリティ監査
• ソフトウェアデリバリ

アカウント構成

AWSアカウント

アンチパターン

• 個人のメールボックスの登録
• 個人の携帯電話でのMFAの登録
• その人が会社を辞めたらどうするの？
• AWSアカウントの設定変更はAWSアカウントでのみ行える、AWSは変更することができません。

ベストプラクティス

• チームのグループアドレスの登録
• ハードウェアMFAを登録
• 会社の住所
• 会社の代表番号
• 基本的にIAMを使いましょう

マルチアカウント構成

アンチパターン

• 混み合った複雑すぎる構成
• 特定のリソースに対する権限所有者がわからなくなる

ベストプラクティス

• ビジネス、資本、開発などの観点でアカウントを分ける

ビジネスごとに分かれた複数のオブジェクトに渡って権限を持つビルドやSecOps用のアカウントについても紹介されました。

ネットワークデザイン

ファイアーウォールと認証

アンチパターン

• ルーティングがセキュアではない
• もぐらたたきのような動的IPの利用
• エンドユーザが識別できない
• 強固な防御ができない
• ハイスケーラブルではない

ベストプラクティス

• AuthNとAuthZの実装
• 特にコアサービスのために利用する
• ハイスケーラブル且つ、監査可能にする
• エッジサービスを組み合わせて強固な防御

Private Subnetからの通信

アンチパターン

• すべてのVPCからDXなどでオンプレを経由してSQSなどのエンドポイントへ通信
• 無理やりなハイブリッド構成
• スケーラブルではない
• 追加のレイテンシー

ベストプラクティス

• パブリック、プライベートのVPCを分けてPeeringで繋ぐ
• プライベートサブネットではDXやVPC Endpointを利用
• パブリックサブネットでは直接パブリックエンドポイントやインターネットの利用をおこなう

セキュリティ監査

セキュリティアンケートについて

アンチパターン

• 一部のカスタマーが監査をする
• 特定の時点でおこない、継続をしない
• スタンダートに基づいていない
• 独立した認証ではない
• ハイスケーラブルではない

ベストプラクティス

• 質問の代わりに証明を
• SOC2やPCIDSSなどで証明を
• 標準的な監査
• コンプライアンスを第３者機関で確認
• 認定を繰り返し実施する
• 継続的な自動監査

利用するサービスについてもなるべくマネージドサービスを利用することでセキュアになります

AWSの公式サイトからトレーニングを受けてセキュリティに対するトレーニングを行うことも有効

ソフトウェアデリバリ

ソフトウェアデリバリ

アンチパターン

• DEV,QA,OPSがそれぞれ分かれている
• 手動のプロセス
• CI/CDがロジック的に行えない
• デプロイ後のセキュリティチェック
• たまにしか行われないリリース
• たまにしか行われないパッチ適用

ベストプラクティス

• DevOpsの実施
• 小規模なDevOps＞DevOps Delivery＞DevOps Quality＞Critical Practice

例）DevSecOps

さいごに

基礎的なアカウントの設計からデプロイまで言及がありました。 アンチパターンとベストプラクティスを比較して考えることでなぜそうしてはいけないのか？なぜそうするべきなのか？を理解できました。データを扱う上でセキュリティへの考慮は常に発生するものです。非常にためになるセッションでした。誰かのお役に立てば幸いです。