【レポート】AWSにおけるクラウドネイティブでセキュアな証券システムの運用 #AWSSummit

こんにちは、岩城です。

2019年6月12日(水)〜2019年6月14日(金)の 3 日間にわたり、 千葉県の幕張メッセにて AWS Summit Tokyo 2019 が開催されています。

こちらで講演されたセッション「AWSにおけるクラウドネイティブでセキュアな証券システムの運用」を聴講しましたのでレポートします。

概要

従来の金融機関において、本番環境の保護は堅牢なサーバールーム等による物理的なアクセスの制限によるものが一般的でした。 しかし、本番環境の物理的な保護は、突破されることがないことを前提としており、万が一それを突破されてしまうと脆弱になるという問題があります。 本セッションでは、クラウドネイティブやゼロトラストのエッセンスを取り入れ、物理的な保護だけに頼らず、安全で柔軟な本番環境を運用するアプローチについてお話します。

スピーカー

• 株式会社Finatext 開発 Lead Developer
  • 石橋 淳志
• 株式会社Finatext 開発 Lead Developer
  • 田島 悟史

※敬称略

レポート

金融をサービスとして再発明する

• コミュニティ株取引アプリ STREAM

STREAMの特徴

• 株取引+コミュニティ
• 日本初従来型手数料ゼロ
• ゼロよりもお得!?SMART取引

アジェンダ

• STREAMシステム
• クラウドネイティブとゼロトラストの実践
• Opsサーバ
• 認証
• 承認
• セキュリティモニタリング
• 今後の展望

STREAMシステム

• すべてのシステムがAWS上で稼働
• AWSを選択した理由
  • 俊敏性のあるサーバーリソース調達が可能
  • サーバリソースの動的な増減が可能
    • 証券システムはザラ場中とザラバ外でシステムの負荷が大きく変動する
    • ザラ場外では不要なサーバリソースを停止する
  • 運用負担軽減と生産性の向上が可能
  • ビジネスのコアな部分に注力できる
• FISCによる安全対策基準・解説書に従ったシステム
• 解説書ではリスクベースアプローチを取り入れることを推奨している
• 自らの環境にとって適切なITガバナンスを検討する必要がある

AWS上での適切なガバナンス

• Fintechリファレンスアーキテクチャー
• クラウドネイティブやゼロトラストの考え方を取り入れることで自らの環境にとって適切でリスクベースアプローチなシステムを構築

クラウドネイティブとゼロトラスト

• クラウドネイティブ
  • オンプレを前提とした従来システム構築の方法論に縛られずクラウドの特性を十分に活かしたシステムを構築すること
  • 単にクラウドを使っているだけの状況を指すわけではない
• ゼロトラスト
  • 脅威はいかなる場所にも存在し、すべての環境は攻撃・侵害される
  • 費用対効果を意識した対策を実施
• リソースを使い捨てにして定期的に再構築して環境をクリーンに保つ
• 動的に権限付与、クレデンシャルは短期間で失効
• マネージドサービスを利用して費用対効果向上を目指す

クラウドネイティブとゼロトラストの実践

• Opsサーバ
  • 本番環境に対してオペレーションをするためのサーバ
  • 一般的には踏み台やGatewayと呼ばれる
• なぜ必要か？
  • プライベートなネットワーク内のリソースへのアクセスの中継
  • 物理的な紛失や盗難のリスクの高い端末に重要なデータを残さない
  • 重要なデータの取扱を効率的に監査
  • 誰でもアクセウできるネットワークは嫌

非クラウドネイティブな手法の例

• 常設で共有のOpsサーバ
• 問題点
  • 常設
    • 本番環境への経路が常に空いている
    • 一度マルウェアに感染すると長期間そのままになる
    • マシン上に重要なデータが蓄積してしまう（CSVやDBのdumpファイルなど）
  • 共有
    • アクセスできるリソースを作業者ごとに制限するのは難しい
    • 接続先や作業者が増えるにつれ不要な通信を空けなくてはならないのがリスク
    • 他の作業者のデータにアクセスできてしまう/されてしまう（権限設定の不備/権限昇格)
    • ホームディレクトリにあるGitHubトークンやSSHキーが見られる

クラウドネイティブな手法

• 使い捨てできる専用のOpsサーバ
  • 必要に応じて起動し、必要なくなったら削除する
  • 複数人で共有しない、自分以外がログインする状況が無いようにする

STREAMにおける運用

• Opsサーバ専用のAWSアカウントを作成
• OpsサーバがあるVPCと本番環境のVPCをピアリング
• 作業者ごとにOpsサーバを起動
• Security Gruop、IAM Policyを作業者ごとに設定
• インスタンス設定はLuanch Templateによって制限
• 作業後Opsサーバを削除する

Launch Template

• インスタンスを起動するための設定情報テンプレート
• AMI ID、インスタンスタイプ、ネットワーク設定
• 特定のLaunch Templateを指定する時のみRunInstanceできるIAM Policyを用意

運用のメリット

• 使い捨て
  • 本番環境の経路が必要な時以外閉じられる
  • マルウェアに感染してもすぐ捨てられる
  • 重要なデータはマシン上に蓄積することがない
• 専用
  • アクセスできるリソースを作業ごとに制限できる
  • 他の作業者のデータにアクセスできる/されてしまうリスクがない

認証

• 認証とは
  • システムに利用者が意図したとおり本人だと確かめること

非ゼロトラストな手法

• 公開鍵認証
  • クライアントが生成した公開鍵をサーバに登録
• 問題点
  • クライアントが保持する秘密鍵の管理が難しい
    • サーバーが増えると鍵が増える
    • 電子的な盗難
    • 共有や使い回し
    • 退職者による持ち出し
  • サーバに設定する公開鍵の管理が面倒
  • クライアントに比例して増える
  • 退職時に大量のサーバを更新しなければならない

ゼロトラストな手法

• SSHクライアント証明書認証
  • サーバにはCAの証明書を登録しておく
  • CAからクライアント証明書を発行
  • 証明書には有効期限を指定する

STREAMでの運用

• Pritunl Zeroを使う
• CAとクライント証明書発行時の認証とユーザ管理を担う
• クライアント証明書の発行はパスワード+2要素認証
• 2要素認証にYubiKeyを仕様
• 証明書は1時間で失効する設定

Pritunl Zero

• ゼロトラストなシステムを構築するためのOSS
  • Webサービス用のProxy
  • SSH 証明書のCA
• 証明書の発行に認証を挟むことができる

U2F

• 2要素認証を強固にし、かつ簡単にするための標準仕様
• 物理デバイスを用いることができる
• YubiKeyが有名
• 認証時にデバイスを物理的にタッチすることで認証が行える

STREAMでの運用

• 公開鍵からCA発行時にパスワードとU2F

この運用のメリット

• クライアント証明書は盗難されても一定期間で執行されるから影響ない
• サーバにはCAの公開鍵を配置するだけでよい
• パスワードはパスワードマネージャを使うので秘密鍵より管理が楽
• U2Fによって認証をするには物理デバイスが必要、オンラインでの攻撃だけでは不正にアクセスできない
• 物理だから盗難にあっても気付く

承認

• 設定作業の内容が正当であることを確認し実施を認めて許可すること
• 複数人でレビュー
• 一人の作業者が悪意を持っていたり、認証情報が盗まられた場合に本番環境への影響を防ぐ

非クラウドネイティブな手法

• 作業者が事前に作業内容文章で記述申請
• 承認者が作業内容に基づき手動で行う
• 問題点
  • 時間が掛かる
  • 申請された作業以外の操作が行われないことを保証するのが難しい
  • 申請どおりの作業がなされたことを保証するのが難しい
  • 緊急時には普段どおりに作業できない

クラウドネイティブな手法

• 自動化された承認フロー
• 作業に必要な最小権限や通信許可をオンデマンドに付与する

STREAMでの運用

• ChatOpsによって承認フローを実現する
• 申請者はSlackを使って作業内容の申請を行う
• アプリケーションを介して権限や通信許可を与える
• 作業終了後に権限や通信許可を削除している
• Slackに変更前と変更後の設定が通知される

メリット

• 運用フローのオペレーションコストを下げる
• 申請することへのハードルを良い意味で下げる
• 一回の大きな変更で不具合があるとロールバックのリスクが出てくるので小さく短期間で変更する
• アプリを介して行っているので削除すべき設定等のヌケモレを防げる

セキュリティモニタリング

• 脆弱性はどんどん発見される、攻撃手法も新しくなる
• すべてのリスクを事前に把握して予防することができない

モニタリングとは

• 不正アクセスを発見するために不審なアクティビティは監視する

非クラウドネイティブな手法

• 同一データセンター内の集約サーバに転送
• 集約サーバ上に監視プログラムをデプロイ
• 不審なアクティビティのチェック
  • awkやgrepコマンドを実行
• 問題点
  • 監視が正しく稼働していることが分からない
  • ログ出力の停止を検知できない
  • ログの改ざんを検知できない
  • 監視プログラムの改ざんを検知できない
  • 不審なアクティビティの検知までに時間が掛かる
  • grepやawkで調査・分析するのは大変

クラウドネイティブな手法

• ログをクラウドストレージに保存
• 監視プログラムをLambdaを筆頭とするFunction as a Serviceな環境にデプロイ
• イベント・ドリブンでの監視

STREAMでの運用

• ログ保存用のAWSアカウントを用意
  • 他のアカウントよりも権限を厳しく管理
• 各種ログをクロスアカウントアクセスで保存
  • S3のオブジェクトロック機能を使って削除・上書きを不可能
• ログ監視用のプログラムをLambda Functionとしてデプロイ
• CloudTrailやConfigの通知をSNSで受信して監視プログラムを実行
• S3バケットのログに対してクエリをけるためAthenaのテーブルを用意する

S3オブジェクトロックとは

• WORMなストレージとしてS3を利用できる
  • Write Once Read Many
  • 書き込みは一回限りだが読み取りは何度でもできる
• 指定した保存期間中S3オブジェクトが削除されないようにする機能
• ガバナンスモード
  • 権限があれば削除できる
• コンプライアンスモード
  • rootユーザでも削除することができない

メリット

• ログの改ざんや削除を防止
• 監視プログラムの改ざんを検知することが簡単
• 不正アクセスを早期に発見できることが期待
• Athenaでちょっと複雑な調査や分析が可能

今後の展望

• OPSサーバのユーザビリティ向上
• Pritunl ZeroのWebサービス用Proxyの利用

感想

前職で証券システムを担当していたので、気持ちがよく分かりました。
オンプレだったので通常時のリクエストの5倍位を捌けるリソースを用意していました。
このためインフラの初期費用が高額になっており、なかなか稟議が通らなかったりしていたことを思い出しました。クラウドって良いなと改めて思えるセッションでした！