開発チームとともに進めるインフラセキュリティの継続的な改善
- 吉澤 政洋さん アンドパッド
- https://speakerdeck.com/muziyoshiz/sre-lounge-17
アンドパッドの開発体制
- マルチプロダクト
- 開発チームがいくつか
- SREチームは横断で見ている
- メインはAWSで一部GCP(Firebaseとか)
- k8sをEKSでECS on Fargateも
- 歴史の長いモノリスとマイクロサービス
- 昔はrubyだったが最近はgo
継続的なセキュリティ診断
- AWS Security Hub
- セキュリティベストプラクティスに基づいてチェックしてくれるサービス
- 定期的なセキュリティチェックはしてるが発見が送れるおそれ
- 自動化したい
- Security Hubで検知されるとSlackに通知されるように
- EventBridgeやSNSを組み合わせて
- StepFunctionSecurityHubのでステータス更新することで同じの何度も通知しないように
- チェックのルールは標準だと255件
- チェック項目を精査
- やむを得ないものは無効化
- 導入して
- 開発初期でリスクに気づける
- 開発チームだけで自発的に完結はまだ難しい
- slackの通知きてるよってsreチームが教えてあげたり
ウィルススキャンシステムの改善
- アップロードされたファイルをs3バケットへの追加時にスキャンしてる
- リプレース前はLambdaでやってた
- 使ってたOSSが開発終了
- Lambdaの実行コスト高い
- 同時実行数
- Antivirus for Amazon S3にリプレース
- 動かす環境の利用費とライセンス費がかかる
- S3にファイル置かれるとSNS topicに流れてSQSに流れてECS上で動くツールで処理実行
- コスト増の予兆検知するためのアラート
- 1日あたりの合計スキャンサイズの
- スキャン実行するECSタスク数
飲食店のインフラサービス “ダイニー” のトラブル対応のすべて
- Hiroaki KARASAWA (karszawa)さん dinii, inc.
飲食のインフラ
- システムが落ちると店舗が回らなくなる
- 予約/注文/調理/会計
大規模障害訓練
- 心構え
- 年に1回は大規模障害が起きていた
- 日夜さまざまな障害が起きている
- →落ちる前提で向き合う必要がある
- エンジニア/ユーザサポート/営業の全メンバーで訓練実施
- 役割
- インシデントオーナー
- 対外発信
- 顧客対応
- 飲食店役
- 振り返り
- 項目ごとにオーナーあげて改善していく
- コストをかけてやってるからアクションにつなげる
- 記憶が薄れないように何回もやる
スタンドアロン機能
ユーザサポートとの連携
- システムアラートはエンジニア
- ユーザからの問い合わせはユーザサポート
WAFでどのリクエストがBlockされたのか、ログを集計してSlackで簡単に見れるようにした
- 是永総一郎さん 株式会社メタップスホールディングス
- https://speakerdeck.com/koresou/wafdedonorikuesutogablocksaretanoka-roguwoji-ji-siteslackdejian-dan-nijian-reruyounisita
AWS WAFのトイル削減
CodeBuild上でGitHub Actionsを動かしてDBマイグレーション効率化
- 森祐太朗さん ウェルスナビ株式会社
- https://www.docswell.com/s/WN_Tech-PR/KJL21J-2024-07-01-102214
DBのデータ移行
- 改善前
- 踏み台サーバが1つを共用
- 手動でやっていてオペミスが怖い-
- 改善案
開発者が安心して実行可能なSQL実行基盤の取り組み
- 多田 貞剛さん 株式会社LayerX
DBオペレーション
- 本番DBのデータを操作したい時
- 踏み台サーバから接続していた
- セキュリティ上の課題
- ダブルチェックしにくい
- ADRソリューション
- Bytebase
- 承認プロセスを経て実施
- DB書き込みはツールから
ポストモーテム運用を導入した話
- 日向野 達郎さん 株式会社BookLive
