6gram to MIXI M / 6gram から MIXI M へ 〜2年間の軌跡〜

ミクシィ x ビットバンク合同LT会 〜2社におけるクラウド活用最前線〜
https://mixi.connpass.com/event/251707/
にて登壇した内容のスライドです。

Transcript

1. 開発本部 / MIXI M事業部 6gram から MIXI M へ ~2年間の軌跡~ ミクシィ x ビットバンク合同LT会 〜2社におけるクラウド活用最前線〜 @ryosan-470 2022/07/01
2. SRE NEXT 2020 でお話ししたことの続き 2 「グループウォレットアプリ6gramの運用をはじめてみた」で調べてみてね
3. 今日お話しすること • 構成について • 前提条件と運用目標 • PCI DSS とは何? • 2年経って最初の運用ポリシーやモットーは守れた？ • まとめ 3
4. 構成について • AWS 環境に構築 ◦ 東京リージョンのみ ◦ Direct Connect を使っている ▪ データセンター3ヶ所にルーターを設置 • バックエンド: Elixir 4
5. 前提条件 • カード情報を取り扱うために PCI DSS に準拠 • 無停止 ◦ 弊社都合のメンテナンスは基本的には行わない • 専属の運用チームや運用者は用意しない ◦ インフラ専任者はいない ◦ みんなでワイワイやっていこうというチームの雰囲気 5
6. 「できる限り運用負荷を減らしたい」 6
7. 運用負荷とは? 7 • 例えばインスタンスが存在すると: ◦ ホスト OS の管理やカーネルパッチアップデート • セキュリティ対策 ◦ ウイルス、脆弱性、侵入検知、ファイル改ざん...
8. 運用負荷とは? 8 • 例えばデータベースサーバー (RDBMS) が存在すると: ◦ スケーラビリティ ▪ 水平方向に増やすのは厄介 ▪ 自由に伸縮すること • 無停止オペレーションの実現の困難さ ◦ マイグレーション ▪ 大きいテーブルになると無停止では難しい ◦ RDBMS 自体のメンテナンス
9. 行き着いた構成 9
10. 完全フルマネージド、サーバーレスな構成 10 AWS Fargate AWS CodeBuild AWS Lambda コンピュート Amazon DynamoDB データベース Amazon CloudWatch Rollbar ロギング
11. この構成は PCI DSS 準拠を行うのも楽 • 多くの要件を AWS に任せることができる ◦ インスタンスが存在しないことで「アカウント」の要件がなくなる • 例えば: ファイル改ざん ◦ ホストマシンは AWS 管理下なので考慮不要 ◦ 動いているコンテナを読み取り専用に 書き込めないんだから改ざんできるわけない 11
12. PCI DSS とは？ • クレジットカード情報を取り扱う事業者が遵守する規則 • 12要件約400項目ある • 毎年 QSA と呼ばれる外部の監査人から監査を受ける ◦ 規模によっては自己問診というのでも OK ◦ 弊社は外部監査を受けています。 • 時代遅れみたいな要件もある ◦ 例: パスワードは90日ごとに変更 12
13. ここまでが2020年当時の話 13
14. 気になるところ 14 • セキュリティインシデントはなかったのか • データベース、DynamoDB 全振りで OK だったのか • 2年間で構成に変化はなかったのか • 2年間インスタンスがなくても問題なかったのか
15. 気になるところ 15 • セキュリティインシデントはなかったのか • データベース、DynamoDB 全振りで OK だったのか • 2年間で構成に変化はなかったのか • 2年間インスタンスがなくても問題なかったのか
16. 「セキュリティインシデント」 はありませんでした！！！ 16
17. 気になるところ 17 • セキュリティインシデントはなかったのか • データベース、DynamoDB 全振りで OK だったのか • 2年間で構成に変化はなかったのか • 2年間インスタンスがなくても問題なかったのか
18. 問題なし 18 時間の都合で詳細はカットします
19. 気になるところ 19 • セキュリティインシデントはなかったのか • データベース、DynamoDB 全振りで OK だったのか • 2年間で構成に変化はなかったのか • 2年間インスタンスがなくても問題なかったのか
20. 2020年初頭に監査人から一言 20
21. 監査人からのコメント 21 • ルーターのログ、保存している? ◦ ログサーバーまたは別媒体に即座にバックアップ • ルーターの時刻同期してますか? ◦ 信頼できる時刻ソースと同期 • ルーターのコンフィグ管理をしていますか?
22. 来年 (2021年) の監査までには解決してね 22
23. どうにかせねば 23
24. データセンター (2020年当時) の状況 24 • ログはルーターの中に保存しているだけ ◦ 何か間違えたりバッファが溢れると消えてしまう可能性があった • 時刻同期はしていない ◦ 信頼できる時刻ソースとは同期しておらず ◦ データセンター内にある弊社別チームの時刻サーバーと同期 • コンフィグ管理はできていない ◦ GitHub で設定されているコンフィグを管理 ◦ 実際にそれ通り設定されているか作業者以外が確認できない
25. なんとかせねば... いろいろと検討と調査をすすめる • CloudWatch は直接ログを受けることができない ◦ エージェントが必須 • AWS には NTP サーバーが存在するが Direct Connect 経由からは直接接続できない ◦ NTPサーバーを買うという手もある 上2点は UDP プロトコルを受けられれば何かできる • ルーターには「HTTPアップロード」という機能がある 25
26. どうしよう... • Network Load Balancer は当時 UDP を受けられたが バックエンドにインスタンスが必要 このために運用負荷が増えるインスタンスの導入はやり たくない • NTP は TCP でも何とかなりそうだがあまり一般的では ない • コンフィグに関しては「HTTPアップロード機能」で何と かできそう 26
27. 行き詰まった 27
28. そんなとき 28
29. Fargate が NLB + UDP のロードバランシングサポートを発表 (2020/07) 29 • ログ ◦ Syslog サーバーを Fargate で稼働 ◦ 受け取った値をそのまま標準出力 → CloudWatch • 時刻同期 ◦ AWS の時刻ソース (Amazon Time Sync Service) にプロキシ ◦ 時刻ソースは原子時計なので信頼できる • コンフィグ ◦ HTTP サーバーを構築 → CloudWatch
30. 2021年の監査: 「問題なし」 30
31. 一件落着 31
32. 気になるところ 32 • セキュリティインシデントはなかったのか • データベース、DynamoDB 全振りで OK だったのか • 2年間で構成に変化はなかったのか • 2年間インスタンスがなくても問題なかったのか
33. 結論 必要になりました 33
34. JCB に続き Visa の導入が決まった 34
35. 仕様書などを眺めてみる 35 • ほとんど今までの構成で動きそう • ただ提供されるソフトウェアが以下でしか動かない ◦ Windows Server ◦ メインフレーム
36. Windows !? 36
37. Windows の懸念 37 • そもそもデスクトップ版しか触ったことがない • どうやって運用するのかすら不明 • インスタンス必要では?
38. インスタンスを利用しないで済む方法はないだろうか? 38 • CodeBuild ◦ Windows 対応 ◦ そもそも提供されるソフトウェアが GUI 必須 • Fargate ◦ Windows 非対応 ▪ 今は利用できるが GUI はおそらく非対応 (未検証)
39. 諦めて「インスタンス」を導入することに 39
40. インスタンスがあると何をしないといけないのか 40 • Windows アップデート • 脆弱性検知 • ファイル改ざん検知 • リアルタイムウイルススキャン • 管理アカウントのパスワード
41. さらにインスタンスの運用負荷をできる限り下げたい 41 • 構成管理はコードで管理できないのか • セキュリティパッチ適用の自動化 • インスタンスのログを CloudWatch に集約 • GUI アプリケーションを何とかできないか ◦ バッチ実行
42. いろいろがんばりました... 42
43. Windows アップデート、セキュリティパッチの自動適用 43 • AWS Systems Manager - State Manager を利用 ◦ パッチが配信されたら自動適用 ◦ 毎日、Windows アップデートが配信されているかを確認
44. 脆弱性検知 • Amazon Inspector を採用 ◦ 毎日定時に Inspector を起動して脆弱性確認 • 実行結果はすべて Slack に通知 44
45. ファイル改ざん検知 • osquery をデーモンとして動かす ◦ 事前にファイルが書き込まれる場所を定義 ◦ 書き込みログをすべて CloudWatch に集約 ◦ メトリクスフィルターで許可していない挙動を監視 ▪ Slack に通知 45
46. その他 • ウイルススキャン ◦ Windows Defender • Windows Server のイベントログなど ◦ CloudWatch のログエージェントにより記録 46
47. その他 • 管理アカウント ◦ パスワードは固定 ◦ 閲覧には権限が必要 ▪ 閲覧者は操作記録が CloudTrail から確認可能 ◦ RDP は Session Manager の機能で利用 ▪ 誰が RDP をしたか特定可能 47 固定パスワードでも安全性を担保
48. 構成管理について • Ansible を採用 ◦ Chef も候補だったが Ruby の依存を嫌って不採用 • VPC 内に CodeBuild を用意しそこから Ansible を適用 ◦ 踏み台インスタンスを不要に • インスタンスの構成自体は CloudFormation で定義 ◦ インスタンスタイプ ◦ ネットワークインターフェース 48
49. GUI アプリケーションについて • 設定に関しては GUI を利用する必要がある • バッチ処理の実行は BAT ファイルからもできる • 実行ログは特定のディレクトリの特定のファイルに書き 込まれる仕組み 49
50. そこで、BAT ファイルを呼び出すエージェントを作成 • エージェントが HTTP で待ち受ける ◦ リクエストを受けるとエージェントが BAT ファイルを実行 ◦ ログを CloudWatch に転送 ◦ VPC内でのみアクセスを受け付けるような設定 • 定時処理 ◦ CodeBuild からエージェントへ HTTP リクエストを行う 50
51. 　何とかインスタンス動いた 51
52. 監査も問題なし 52
53. Windows インスタンス導入編のまとめ • 意外と Linux インスタンスに近い構成で運用できる ◦ だがそこまで Windows の機能を使っていないだけだからかも ◦ 台数も1台しか管理していないし... • AWS Systems Manager はいろんな機能がある ◦ Fleet Manager で設定されているレジストリをみて編集できる ▪ 特定のレジストリを設定する必要がある時にいちいち RDP しなくてよい ◦ Session Manager の RDP はWebブラウザ経由でできるようになった ▪ リモートデスクトップクライアントは不要 • 構成管理は重要です ◦ 構築後に誤ってインスタンスを壊したこともあったが簡単に再構築 53
54. 全体のまとめ • 構成は大きく変わらずにすみました • 完全フルマネージド、サーバーレス構成オススメ • クラウド環境外のリソースのことを忘れがちなので注意 ◦ しっかり構成図を書いておくことよいです • 構成管理はしっかりやろう 54