SRE Lounge 17 参加レポート

久しぶりにオフラインかつ登壇しない勉強会に参加してきました。

sre-lounge.connpass.com

開発チームとともに進めるインフラセキュリティの継続的な改善

吉澤 政洋さん（@muziyoshiz） / 株式会社アンドパッド SRE

アンドパッドのSREチームは、マルチプロダクト開発を行う複数の開発チームを支援するために、さまざまな取り組みを行っています。この発表では、開発チームとともにインフラセキュリティを継続的に改善していくための、最近の取り組み2件（継続的なセキュリティ診断の導入、ウイルススキャンシステムのリプレースおよび運用改善）をご紹介します。

開発体制

• 各開発チームの横断型としてSREチームがある

システム構成

• メインはEKSで一部ECS for Fargate
• EKSクラスタはモノリス、マイクロサービスの2つ。
• 以前はRubyだが、今はGoで開発されていることもある

継続的なセキュリティ診断の導入（AWS Security Hub）

• 開発チームにインフラ構築など一部移譲している
• Security Hubで検知されたらSlack通知していて、基本的に開発チームで見るが、どのチームもスルーしている場合はSREチームが拾って適切なチームに振る

有効化するコントロールの精査

• Security Hub導入前に関係者への確認を繰り返して、有効化する必要があるコントロールを精査した

通知システム

• AWSサービスのみで構成。AWS Lambda不要
• Security Hub → EventBridge → SNS → AWS Chatbot → Slack
• Step Functionsで重複通知や対応しないものを除外

ドキュメント整備

• 検出結果の確認、対応方法の手順書
• コントロール一覧（スプレッドシート）
  • コントロールの説明、現在の設定、コントロールを無効化した理由、チェック対象外にしたリソースとその理由
• 通知の多いリソースに関する推奨設定
  • AWSマネジメントコンソールの設定方法とTerraformでの設定方法の両方をドキュメント化している

導入してみて

• 開発チームの自発的な確認はまだ難しい。SREチームからの声掛けが必要
• Slack通知に改善の余地がある

ウイルススキャンシステムのリプレースおよび運用改善（Antivirus for Amazon S3）

詳細はアンドパッドさんの技術ブログで公開されています。

tech.andpad.co.jp

• リプレイス前はAWS Lambda関数でウイルススキャンするOSSをフォークしてつかっていた
• OSSの開発終了と、AWS Lambdaの実行コスト増加の課題があってリプレイスすることになった

コスト急増の予兆検知のためのアラート

• 各S3バケットの1日あたりの合計スキャンサイズ
• AWSリソースのコスト
  • コスト配分タグ
• スキャン実行するECSタスク数

開発チームのためのドキュメント整備

• S3とAntivirus for Amazon S3の管理画面が異なって確認しづらい
• 棚卸し用シートの自動生成
  • SREチームから開発チームに依頼するための棚卸しシートを自動生成
  • 開発チームはそのシートに書かれているS3バケットだけを見れば良い

飲食店のインフラサービス “ダイニー” のトラブル対応のすべて

Hiroaki KARASAWA(@karszawa)さん / dinii, inc.

飲食店の営業を支えるモバイルオーダー POS サービスのダイニー。毎晩のように戦場と化す飲食店の現場はダイニー無しでは回らない。じゃあダイニーが落ちたらどうなるの？店長、これヤバくないっすか（スタッフ談）。そんなダイニーを落とさないために何をしているのか、落ちたとしても大丈夫なように何をしているのか、その辺りを語ります。

Keywords: Observability, Incident Response, Emergency Drill.

大規模障害訓練

なぜするのか？

• 大規模障害に対する心構え
  • 経験：年に一度は必ず大規模障害が起きている
  • 歴史：日夜さまざまなサービスで障害が起きている
• 必ず起こることだから。だからそれに備えておく。

計画

• エンジニア以外にユーザーサポート、営業の代表が集まりシナリオ設計する
• 当日は、エンジニア、ユーザーサポート、営業の全メンバーを集める

実施

振り返り

• すべてを洗い出す

成功させるためのポイント

• 全員を集める
• 振り返りのクロージングに責任を持つ
  • 必ずアクションしてクロージングする
• 何回でも繰り返す
  • 社員が増えていくとインシデントの記憶が薄れていく
  • Slackチャンネルに #remember_20220811 というのがあって当時のSlackログが残っている

スタンドアロン機能

• 一部の顧客に対してSLAを設定している
  • SLAを設定すること = ダウンタイムの体験設計をする
• スタンドアロン機能 = 店内の様々な機能をローカルネットワーク内で動かす機能
• ローカルネットワーク内で動かすのは相当大変
• これが強固な参入障壁になっている

サポート体制

• システムアラートはオンコールエンジニア
• ユーザーからの問い合わせはユーザーサポート
• 適宜エスカレーション
• 毎週リリースノート
  • エンジニアしか理解できない言葉で書かない

インシデントレポート

書籍『システム障害対応の教科書』を参考にした。

https://www.amazon.co.jp/dp/B0CW17TNRWwww.amazon.co.jp

• 顧客がどのぐらい困っているか
• 究極、顧客が困っていなければ何の問題もない
• インシデント対応の目的 = 顧客の目の前の業務を回復すること
  • まずは復旧が優先

オンコール体制

• 24時間ごとにローテーションでほぼすべてのエンジニアが対応する
• オンコールの心構え：顧客の目の前の業務を回復すること

システムメトリクスダッシュボード

• アラートが鳴ったらとりあえず見に行く場所

WAFでどのリクエストがBlockされたのか、ログを集計してSlackで簡単に見れるようにした

是永総一郎さん / 株式会社メタップスホールディングス

WAFでブロックしたアクセスが一定数以上に達するとアラートを飛ばすようにしていますが、毎回詳細を調べるのが面倒なためLambdaで集計してSlackで確認できるようにした話をします。

テーマ：AWS WAFに関するトイル削減について

• AWS WAFでブロックしたアクセスが一定ラインを超えたらDatadogでアラートしているが、通知が多い。多いときは5〜6件/日
• Datadogの通知がきた後に大まかな内容をSlack通知するAWS Lambdaを構築した
  • URL、検索用Athenaクエリ etc

WAFログを深堀りしてWAF運用を定期的に見直す

• WAFログから攻撃を学ぶ
• ルールの調整
  • 意図しないブロックがないかを確認する。特にマネージドルールで設定している場合
• 訓練
  • 実際にシステムに攻撃してみて守れているかを確認する

CodeBuild上でGitHub Actionsを動かしてDBマイグレーション効率化

森祐太朗さん

www.docswell.com

構想段階でLT登壇するという、ものすごい登壇ドリブンでした。
金融系というのもあり、DB操作へのフローをかなりキッチリ構想をされていた印象でした。

開発者が安心して実行可能なSQL実行基盤の取り組み

多田 貞剛(@taddy_919)さん / 株式会社LayerX**

バクラク事業部では支出管理をなめらかに一本化するSaaS「バクラク」を開発しており、合計6プロダクトを提供しています。システムの運用において、お客様の重要なデータを変更するオペレーションが発生します。お客様の重要なデータをより安全に扱うため、安全で確実な作業ができる基盤に移行し、運用しています。それにまつわるお話をします。

課題

• 本番DBを操作する場合、今までは踏み台サーバ経由でRDSにアクセスしていた
• 踏み台サーバで色々できてしまいセキュリティ面でよろしくない
• Wチェックがやりづらい

基盤紹介

• Bytebase
• データ変更の履歴を残しながら承認プロセスを経てデータ変更ができるようになった

詳細はLayerXさんのテックブログで公開されています。

tech.layerx.co.jp

ポストモーテム運用を導入した話

日向野 達郎さん / 株式会社BookLive

障害対応の振り返り(ポストモーテム)運用を導入し始めました。期待していたメリットや、思いがけず得られたメリットなどをお話しします。

課題

• チームメンバーの増減があって知識のサイロ化があった

ポストモーテム運用に期待すること

• ポストモーテムを共有することでサイロ化の解消
• ドキュメント化の文化醸成

おわりに

勉強会の後に予定があり、懇親会に参加できなかったのが残念でしたが、個々の発表はとてもおもしろく、最近はインシデント対応やセキュリティ対応などで悩んでいたので大いに学べるものが多いイベントでした。