スケールするサービスでの最新オペレーション事例

https://www.youtube.com/watch?v=B1Wt8s4LEfk

1 comment | 0 points | by WazanovaNews 約2時間前 edited


Jshiike 約2時間前 | ▲upvoteする | link

10/29に開催されたSecurity@Scaleのカンファレンスで、興味深いと思った話題を拾ってみました。

SquareのDiogo Monicaの講演は、障害/脆弱性に対応する社内システムをどのように自動化 / 最適化させてきたかというテーマ。

  • 脆弱性の種別(XSS等) x セキュリティゾーン(システムのどの箇所にとって脅威になるかを3段階に分類。DBに近い方が危険性が高い。)でスコア化することで、対応のために発行されるチケットは自動的に優先付けされる。
  • SLA(サービスレベルアグリーメント)において、例えば、P0は24時間以内、P1は7日以内、P2は30日以内と基準が明示されているので、いつまでに対応されるのか共通の認識が持てている。
  • チケットは脆弱性の対象となるチームのマネージャに対して発行される。SLAの期限を満たせなかった案件は週次で、VP of Engineeringも出席し、振返りミーティングを持つ。VPが出席するかしないかで、期限に間に合わないP2案件数がわかりやすいくらい増減したので、この形式とした。
  • 社内メンバのUserDBを用意し、全てのアプリに対して、OpenLDAPを使ってアクセス権限の集中管理をしている。簡単なクリック操作で設定できるJavaScriptのインターフェースに加え、各アプリの開発チームには、OpenLDAPとやりとりできる、RESTfulでテスト可能なAPIを提供。

  • アクセス権限の追加は、アプリストア風の管理画面からリクエストし、各アプリの開発チームのマネージャーが承認する仕組み。付与された各アクセス権限及びそれらの権限でできる各アクション単位で有効期限設定があり、一定期間アクティビティがないと無効になる仕組みなので、最低限必要な権限に自動的に最適化される。

  • Hadoop + Hiveをバックエンドにもつアラートシステムは、前述のUserDBと連携していて、その日の各チームの当番のエンジニアが誰かを把握している。適切なアラートが適切なチームの担当者のみに振り分けられ、通知される。セキュリティチームには、「当該アプリの担当者からの協力依頼 or 既知のアラートではないとの通知」「当該アプリの担当者の対応時間がタイムアウト」というトリガーのいずれかがない限りは、アラートはエスカレーションされないので、以前のように大量のアラート通知をモニタリングする苦痛から解放され、夜寝られるようようになった。

  • システムのどういう振舞いがアラートに起因しているのか、担当のエンジニアが把握するのは手間のかかる作業。そこで、アラート毎に、どのマシンにおいてどのアクションが起きていたのかという情報をわかりやすく時系列で表示するダッシュボードを用意した。

  • 各wシステム間の依存関係をうまく分離化して整理できれば、順次オープンソースとして提供していきたい。

FacebookのMike Arpaiaの話は、SQLクエリでOSのステートを操作することのできる osqueryの紹介。

  • オープンソースとして提供。
  • Linux & OSXに対してSQLで、プロセスの実行 / カーネルモジュールのロード / アクティブネットワークの接続 / ルートテーブル操作 / ファイアウォールの設定 / ソフトウェアのインストールなどができる。Joinを利用することで、考えつかなかったような複雑な操作を取りまとめる事例がでてくると思う。
  • ローレベルのホストのモニタリングをするデーモンの機能もあり、クエリ結果の時系列での変化を確認できる。
  • 設定とログについて、シンプルなプラグインAPIを用意。

#facebook, #square, #セキュリティ #障害対応, #devops


ワザノバTop200アクセスランキング


Back