[レポート]Finatextによるセキュリティとアジリティを両立する為の秘訣 – AWS Security Forum Japan 2023 #aws #awssecurity

こんにちは、臼田です。

みなさん、AWSのセキュリティ対策してますか？(挨拶

今回は2023年10月12日にオフラインで行われたAWS 国内最大のセキュリティイベントであるAWS Security Forum Japan 2023の下記セッションのレポートです。

Finatextによるセキュリティとアジリティを両立する為の秘訣

Finatextでは保険・証券会社などに対して、AWSを活用した基幹システムをSaaSにて提供しています。金融サービスでは高度なセキュリティが求められる一方で、常にサービスを進化させ続ける為のアジリティも犠牲にする事は出来ません。本セッションでは、金融業界だけでなく企業のCISO/CTOやセキュリティ担当者を悩ませる「セキュリティ」と「アジリティ」のトレードオフを解決する為の実践的なノウハウについてお話します。

株式会社Finatextホールディングス 取締役CTO / CISO 田島 悟史氏

アマゾン ウェブ サービス ジャパン合同会社 技術統括本部 ストラテジック金融ソリューション部 ソリューションアーキテクト 豊原 任

レポート

• AWS豊原さん
  • 普段は金融業界のお客様を支援
  • セキュリティとアジリティの両立の目的と実現方法を説明
• セキュリティとアジリティの両立
  • ITはビジネスを成功させるためのもの
  • ビジネスの価値の創出をし、迅速にし、セキュアにやる必要がある
  • イノベーションのためにセキュリティとアジリティを両立する必要がある
• 得られるメリット
  • ソフトウェアの脆弱性を早期に発見することで修正のコストを削減
  • テストを自動化することで市場投入までの時間を短縮
  • 文化づくりにより潜在的な問題をプロアクティブに八卦ね切る
• どう両立させるか
  • 社内規定やプロセスによるコントロールとAWSサービスによる自動化と継続改善
  • 具体例は後ほど
• AWSアカウント利用のパターン
  • シングルアカウントアーキテクチャ
  • マルチアカウントアーキテクチャ
  • AWSはマルチアカウントアーキテクチャが推奨
• アカウントを分割することによってビジネス要件に基づいた管理ができる
  • 環境分離
  • 請求分離
  • ビジネス推進
  • ワークロードの分離
• 環境の分離
  • 開発環境に対する過剰な統制を回避してアジリティを向上できる
• 権限分離
  • 環境ごとに権限を分けることができる
• ログの集約
  • 操作履歴の追跡調査や監査に備える
  • アカウントから話すことで回zンや削除から保護する
  • ガバナンスの強化ができる
• ここまでのまとめ
  • イノベーションのためにセキュリティとアジリティを両立させる
  • マルチアカウントアーキテクチャはベストプラクティスとなる
• Finatextの取り組み
• 田島さん
• サマリー
  • 金融業界でのDevOpsの実現のためにTwo-Person Integrity(TPI)を実現している
    • • TPIの説明は後ほど
  • TPIの実践がセキュリティとアジリティの両立の秘訣と考えている
  • TPIの実現やその保管のためにAWS Organizationsを軸にマルチアカウント構成
• 自己紹介
  • 2019年に入社し2022年より取締役CTO/CISO
• 会社紹介
  • 株式会社Finatextホールディングス
  • Vision: 金融がもっと暮らしに寄り添う世の中にする
  • Mission: 金融をサービスとして再発明する
  • 金融の基幹システムをSaaS型で提供
    • オンプレミスのリスクを回避したい
  • 証券・保険・敷金の領域で事業を展開
• セキュリティとアジリティ
  • セキュリティ
    • 一般論としてセキュリティは情報の気密性・完全性・可用性を確保すること
    • 金融領域においてはお客様の資産・個人情報等の重要な情報資産を守るために非常に重要な概念
    • FISC安全対策基準等のガイドラインの遵守も重要
  • アジリティ
    • 敏捷性や素早さのこと
    • 金融がもっと暮らしに寄り添う世の中を実現するためには素早く柔軟なサービス改善が必要
  • この両立が必要
• 職務分離とDevOps
  • 職務分離とは
    • 主に不正防止の観点で業務組織の分離や業務の分担を行うこと
    • FISC安全対策基準の統制基準においてもその必要性が言及され相互牽制体制を整備することとある
  • 開発と運用の分離
    • 金融において最も一般的な手段として開発と運用を分離する
    • 一方でこれは多くの弊害を生む
    • インセンティブの違いにより対立構造
    • 経験獲得や能力成長の偏り
  • DevOpsの重要性
    • 開発部門と運用部門を分けるのではなく1つのチームに開発と運用の両方の権限と責任をもたせる体制
      • FISC安全対策基準の最新の第11版においてはDevOpsの採用について言及されている
      • 相互牽制田製の実現が別途考慮が必要
• Two-Person Integrity(TPI)
  • TPIとは
    • 重要なデータへのアクセスやリスクの高いオペレーションに関して単独での実行を付加にし2人以上の関与を必須とするアクセス管理の手法
    • Two-Person Ruleと呼ばれることもある
    • DevOpsでTPIを取り入れる
    • TPIをできる限りクラウドネイティブに実現することも重要
    • NISTの用語集にもTwo-person Ruleが書かれているので勝手に定義している概念ではない
  • AWSリソースのデプロイに関するTPI
    • 前提としてインフラ構成はIaCにより原則コード化
    • コードの管理にはGitHubを利用
      • リポジトリにRequire approvalsを適用している
      • ブランチプロテクションの機能
      • 必要なメンバーによる承認がない限りマージできなくなる
    • Atlantis
      • TerraformをGitHub経由で運用できるようにするツール
      • 設定によってterraform applyする前にPRが承認されていることを必須としている
      • Atlantisがterraform planをして結果をPRにコメントする
      • レビュアーがその結果もチェックしてapplyする
      • 開発者が一人でデプロイ出来なくしている
      • plan結果の具体例などは後で公開される資料で
  • AWSリソースのマニュアル操作に関するTPI
    • どうしても一部はマニュアル操作しなと行けない
    • GatewayアカウントからのAssumeRoleを用いている
    • 一時的なAssumeRoleの特権付与のためのTARPというツールを内製している
  • GatewayアカウントからのAssumeRoleを用いている   各種ワークロードにはIAM Userヲ作成していない
  • TARP(Temporary AssumerRole Policy)
    • 一時的な権限付与をする
    • 自動でIAM Policyが削除される
    • 本人以外が承認しないと行けない
    • 実装はLambdaでしている
  • AWSでもTEAM(Temporary Elevated Access Management)をOSSで公開している
    • これはIdentity Centerを使っているが同じようなツール
  • データベースアクセスへの直接アクセスは極力避けるべきであるが0にはできない
    • Opserverという踏み台を構築している
    • データベースにアクセスするためのセキュリティグループの設定を承認付きで動的に付与して自動開放する仕組みで実現
  • ルートアカウントのTPI
    • ルートアカウントは強大な権限を持つためTPIを最も必要とする部分
    • ルートアカウントはSecurity Key(YubiKey)によるMFAを設定している
    • パスワードの管理者とMFAデバイスの管理者を分離している
• TPIの補強
  • TPIによるアクセス管理だけで十分にセキュアに情報資産を保護できるわけではない
  • 悪意の有無なども考慮する必要がある
  • 監査ログの保存
    • TPIによって取得した権限で監査ログの削除・改ざんが行われる
    • Amazon CloudTrail等の監査ログは専用のAWSアカウントのS3 Bucketに保存
    • S3のObject Lockを使いWORMなストレージによる保護も実施
  • バックアップの保護
    • ログの削除と同じようなリスク
    • AWS Backupにより取得・管理
    • AWS BackupのVault Lockで保護
  • リアルタイムなモニタリング
    • TPIによって取得した権限で想定しない高リスクな操作が行われる
    • Amazon CloudTrailのログを常時監視しリスクの高いオペレーションが行われた場合に通知を飛ばす
    • AWS OrganizationsのSCPを組み合わせることで高権限を持った状態でもモニタリングの仕組みを解除することは出来ないようにしておく
  • CSPMの活用
    • リアルタイムなモニタリングでカバーできない高リスクな操作や厚生の補足にCSPMを利用する
    • AWS Security HubとAWS Trusted Advisorを活用
    • GitHubについては、内製のシステムを構築して監視
    • Require approvalsの設定が有効になっていることを担保
• DevOps with TPIの実践結果
  • セキュリティとアジリティへの寄与
    • 17の企業が金融機関システムとして使っている
    • セキュリティ麺での信頼を得られている
  • 週あたりのAWSリソースの更新数が400
    • 金融では3ヶ月に1度の変更などの文化もあるが、その中では更新数が多いと考えている
    • 新入社員でもDay1からコミットできる
• まとめ
  • 様々な領域でTPIを実践している
  • 実現するためにさまざまなサービスを組み合わせて効率的に実践している

感想