https://ozaki25.hatenadiary.jp/entry/2024/08/03/175528

組織的なインシデント対応を目指して〜成熟度評価と改善のステップ〜

インシデント対応をサポートするサービスを作ってる
インシデントレスポンスの改善は各社違うので難しい
- A社でうまくいったからといってB社でうまくいくとは限らない
- 期待値も会社ごとに違う
- ベストプラクティスがはまらないこともある
成熟度モデルを使う
- SREのコンテキストを取り込む
- 何から着手するかなど整理できる
- モニタリングなどできてるかの影響を受ける
信頼性のマインドセット
- 組織の信頼性を5つの段階に分けたもの
- プロダクトライフサイクルに応じてどの段階にあるべきか変わってくる
- これに沿って成熟度モデルを作りたい
評価指標
- 信頼性のマインドセットを元に成熟度モデル4段階を作った
- もっと細かい指標も必要
  - それぞれインシデントの対応前/中/後でフェーズを分けた
  - 各フェーズごとに観点が3つあってそれぞれ4段階のどこかを見る
- これを使うと現在地がわかって劣ってる部分がわかる
  - 自分たちがどうあるべきかディスカッションしてアクションをとっていく

DevSecOps
- 全開発プロセスで脆弱性が入り込むリスクを低減する
内回り
- 開発初期からセキュリティを取り込む
- Shift Left
- パイプラインへのセキュリティ対策の統合
- 網羅的な担保は難しい
外回り
- デプロイ語の運用環境のセキュリティ
- 実行中のコンテナイメージのスキャン
- 実行環境のミスコンフィグスキャン
- これだけだと大変
具体的な運用
- スクラムなど各自の開発フローに組み込む
  - 開発チームが自分たちで運用を決める
- 優先度を決める
  - どんな脆弱性をいつまでにやるか
組織に定着させる
- 組織としての温度感
- 開発チームの余力
- リポジトリの数
開発チームへの定着
- セキュリティ対応の必要性理解
- タスクに組み込む
  - 追加対応としない
- セキュリティ責任者をチーム内に
  - セキュリティの部門とのパス
- 定着するまでは専任部隊と一緒に模索

ほぼ全てのシステムをAWSに移行しようとしてる
AWSに移行することで負荷試験の重要度が高まった
DLT
- Distributed Load Testing
- 負荷試験をするためのツール
- AWSのマネージドサービスを組み合わせて使える
- CloudFormationで一発で構築できる
- JMeterのシナリオをアップして実行できる
- AWSのサービスを組み合わせてるだけなのでカスタマイズができる
どうしてDLTを使ったか
- 本来負荷をかけたくない箇所に負荷をかけることを防ぐ
  - 社内proxyとか
- 本来負荷をかけたい箇所に負荷をかけられないことを防ぐ
  - FWやLB
計画やテストに時間を使って準備は用意されてるもので楽をするといい

FIS
- AWS Fault Injection Service
- AWSのサービスで障害が起こった時にどういった挙動をするか試せる
- シナリオのパターンもAWSで用意してくれてる
  - 停電になった時とか
DLTと組み合わせてアクセスが来てる時に障害がおきたときを再現する
- 全部を完璧に再現できるわけではないので手動で再現が必要なところもある
- 全てテストできるわけではないがやれることも多い