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