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