エンジニアと気軽に繋がれるプラットフォーム「ハッカー飯」で行った セキュリティ・モニタリングに関する取り組みについて

スタートアップ事例祭り 〜監視・モニタリング・セキュリティ編〜
https://aws-startup-community.connpass.com/event/241721/

Transcript

1. エンジニアと気軽に繋がれるプラットフォーム「ハッカー飯」で行った セキュリティ・モニタリングに関する取り組みについて 菊池 宣明
2. 自己紹介 菊池 宣明 • 主に SRE 関係の仕事を担当 • 今年からハッカー飯の開発メンバーとしてジョイン 経歴 • 科学系の大学院を卒業→ CIer（新卒） → 独立 • エンジニア5年生 趣味 • ゲーム（スマブラ、Fortnite） 好きな AWS サービス • AWS サポート @kikulabo
3. ハッカー飯とは？ 技術や知識でアイデアを形にする人々(=ハッカー)が、 ご飯を囲むような気軽さで、語り合い、教え合い、繋がれるオンラインプラットフォーム
4. • 会社概要 ◦ 会社名： 株式会社スタークロス ◦ 代表取締役: 西田宗太郎 • ハッカー飯の特徴 ◦ 話したいことをもとにエンジニアと1 on 1マッチング ◦ 複数人とエンジニアと簡易的なイベントを行う、食事会 ◦ 興味のあることをもとに集まるコミュニティ機能 • サービス開発の背景 ◦ アイデアを形にするエンジニアが周りにいない ◦ 他の企業に勤めてるエンジニアの生の声が知りたい ◦ 技術雑談をして新しい発見をしたい などなど、エンジニアと気軽に話せる環境が周りにあまりないといった課題を解決するため ハッカー飯とは？
5. ハッカー飯の特徴
6. ハッカー飯の特徴
7. ハッカー飯の特徴
8. ハッカー飯の特徴
9. ハッカー飯の特徴
10. ハッカー飯の運営・開発について • 運営に関して ◦ メンバー全員それぞれ本業がある中、副業でハッカー飯に携わっている • 開発スタイル ◦ 毎週土曜日に Discord のボイスチャンネルに入室し各々開発を進めていく ◦ 1時間開発して10分間休憩（スマブラ）をするというサイクルで行っている ◦ 夜に定例を行いそれぞれのタスクの確認や今後の方針について話し合う • 収益化に関して ◦ 現状収益化がまだ出来ていないのでコストを抑えた構成となっている ◦ 今後法人版のハッカー飯を作り、企業の中のエンジニアと気軽に繋がれるようなシステムを構築する予定
11. 本日お話しする内容 • セキュリティ ◦ Lightsail を EC2 へ移行した話 ◦ IAM ユーザの管理 • モニタリング ◦ New Relic 導入の話
12. 本日お話しする内容 • セキュリティ ◦ Lightsail を EC2 へ移行した話 ◦ IAM ユーザの管理 • モニタリング ◦ New Relic 導入の話
13. ハッカー飯のインフラ構成の概要（初期）
14. ハッカー飯のインフラ構成の概要（初期）
15. Lightsail とは？ https://aws.amazon.com/jp/lightsail/
16. Lightsail の選定した3つの理由 • 理由①: コスト管理を行いやすいから ◦ 定額で使用できるため予算を立てやすい ◦ $3.5 のプランを使用すると EC2 の一番安いインスタンスタイプを選択して1ヶ月稼働した金額よりも安くなる
17. • 理由②: 環境の構築を簡単に素早く出来るから ◦ 数クリックで環境を構築できるのは当時の開発メンバーにとって都合が良かった Lightsail の選定した3つの理由
18. Lightsail の選定した3つの理由 • 理由③: EC2 への移行も可能 ◦ Lightsail 上で取得したスナップショットを簡単に EC2 へエクスポートを行える
19. Lightsail を使っていて困ったこと • Lightsail に IAM ロールを使用できない ◦ EC2 のように必要な権限を付与した IAM ロールを作成してアタッチするといったことが出来ない ◦ IAM ユーザを作成しアクセスキーをインスタンス内部に格納する必要がある • スケールアップが簡単に出来ない ◦ EC2 のようにインスタンスを停止しスケールアップして起動という操作が Lightsail では行えない ▪ Lightsail の場合スケールアップするにはスナップショットから作り直す必要がある ◦ 今後サービスが広く認知されアクセス数が増えた際に困りそう
20. Lightsail から EC2 へ移行 • アクセスキー/シークレットキーがハードコーディングされており誰でも見れる状態になっていた • 今後開発メンバーが増えてきた際にセキュリティ上リスクなると判断し、 IAM ロールを使用できる EC2 へ移行 ◦ 移行の流れ 1. Lightsail を EC2 へエクスポート 2. 適切な権限に絞った IAM ロールを EC2 にアタッチ 3. 使用していたアクセスキーを無効化しテストを実施 4. 問題ないことを確認出来次第アクセスキーを削除
21. IAM ユーザの管理 • AWS コンソールへのログイン等がこれまで Root ユーザで行われていた • アクセスキーの使用を無くしたタイミングで IAM ユーザ管理の見直しを実施 • ハッカー飯では簡単にセットアップできてユーザ管理を効率化出来る AWS Single Sign-On を採用
22. • AWS SSO を使用することでユーザー/グループの管理および認証を行える ◦ ポータルサイトにログイン後、所属しているグループに付与されている権限のみ使用を制限を出来る AWS Single Sign-On（SSO） について
23. 本日お話しする内容 • セキュリティ ◦ Lightsail を EC2 へ移行した話 ◦ IAM ユーザの管理 • モニタリング ◦ New Relic 導入の話
24. 監視導入の背景 ① ② ③ ④ .NET 5 から .NET 6 へ バージョンを上げるぞ！ ハッカー飯運営
25. 監視導入の背景 ① ② ③ ④ .NET 5 から .NET 6 へ バージョンを上げるぞ！ ハッカー飯運営 インフラ側の必要な作業を行わずに作業を終了
26. 監視導入の背景 ① ② ③ ④ .NET 5 から .NET 6 へ バージョンを上げるぞ！ ハッカー飯にログイン出来ない人が発生 ハッカー飯運営 インフラ側の必要な作業を行わずに作業を終了
27. ユーザが連絡することで運営側が障害を認知 監視導入の背景 ① ② ③ ④ .NET 5 から .NET 6 へ バージョンを上げるぞ！ インフラ側の必要な作業を行わずに作業を終了 ハッカー飯にログイン出来ない人が発生 ハッカー飯運営
28. • 反省点 ◦ 必要な操作が本番環境で実施されていなかった ▪ 改善点: 手順のレビュー制度の導入や Ansible 化を実施 ◦ ハッカー飯が正常稼働しているかどうかをそもそも運営サイドが認知できていない ▪ 改善点: モニタリングツールの導入 • よりユーザ体験を向上させるためにモニタリングツールの導入を優先的に実施 障害内容の振り返り
29. • CloudWatch と SaaS 製のモニタリングツール ◦ どちらも出来ることは大方一緒（のはず）で、得意分野がそれぞれ異なる。 ◦ CloudWatch ▪ AWS リソースを手早くモニタリングすることが出来る ◦ SaaS 監視ツール ▪ マルチアカウント/クラウドの管理が得意 • 将来的にマルチアカウント/クラウド化しても大丈夫なようにハッカー飯では SaaS 監視ツールを採用 モニタリングツールの選定
30. New Relic について • ハッカー飯では New Relic という SaaS 製の監視ツールを導入 ◦ 選定理由: １ユーザであれば全ての機能を期間制限なく無料利用枠で使用できるため ▪ ※月間100GBまでのデータ容量であれば無料（他にも制限は存在します） • New Relic の主な機能 ◦ Telemetry Data Platform ▪ テレメトリデータを収集・格納する場所。チャートやダッシュボードを作成することも出来る。 ◦ Full Stack Observability ▪ 収集したテレメトリーデータを分析・可視化することが出来る機能。 ◦ Alert and Applied Intelligence ▪ 閾値ベースのアラート設定や、異常値の検出やインシデントの予測等を行う機能。
31. • ハッカー飯では New Relic という SaaS 製の監視ツールを導入 ◦ 選定理由: １ユーザであれば全ての機能を期間制限なく無料利用枠で使用できるため ▪ ※月間100GBまでのデータ容量であれば無料 • New Relic の主な機能 ◦ Telemetry Data Platform ▪ テレメトリデータを収集・格納する場所。チャートやダッシュボードを作成することも出来る。 ◦ Full Stack Observability ▪ 収集したテレメトリーデータを分析・可視化することが出来る機能。 ◦ Alert and Applied Intelligence ▪ 閾値ベースのアラート設定や、異常値の検出やインシデントの予測等を行う機能。 New Relic について メトリクス、イベント※、ログ、トレースのことを指す ※New Relic Agent が送信するデータ
32. Telemetry Data Platform について • Agent をインストールすることでテレメトリーデータを Telemetry Data Platform に送信することが出来る • テレメトリーデータを基にダッシュボードを作成することも可能
33. • New Relic APM ◦ アプリケーションのパフォーマンスの計測を行える機能 Full Stack Observability について Webリクエストの処理に費やす平均時間
34. Full Stack Observability について • New Relic APM ◦ アプリケーションのパフォーマンスの計測を行える機能 1分間に処理するリクエストの数
35. Full Stack Observability について • New Relic APM ◦ アプリケーションのパフォーマンスの計測を行える機能
36. • Apdex Score について補足 ◦ ユーザ満足度を定量的に表したもの ◦ レスポンスタイムの閾値を T とした時、リクエストを以下の3つのレベルに分類 ▪ <満足> レベルのリクエスト: レスポンスタイム ≦ T ▪ <許容可能> レベルのリクエスト: T ＜ レスポンスタイム ≦ 4T ▪ <不満足> レベルのリクエスト: 4T ＜ レスポンスタイム ◦ リクエストを分類後、下記の計算式を用いて Apdex Score を算出 ▪ 0～1 の値を取り、0が最悪のスコア、1が最高のスコアとなる Full Stack Observability について
37. Full Stack Observability について • New Relic Infrastructure ◦ CPU、メモリ、ディスク IO やネットワークトラフィックを観測することも出来る
38. Full Stack Observability について • New Relic Synthetics ◦ システムに対して外部から稼働状況を確認する機能（外形監視）
39. Alert and Applied Intelligence について • New Relic Alert ◦ アラートの設定および通知先（Email、Slack、PagerDuty 等）を設定する機能
40. New Relic 使って実践していること • ユーザに影響が出そうなものをアラートとして設定 ◦ 外型監視、エラー発生率、レスポンスタイム等 • 1週間に一度メトリクス全体を一通り確認 ◦ アラートが発生していなくとも異常が発生していないかを確認するため ▪ 確認ポイント • エラーが起きていないか • レスポンスタイムに異常が起きていないか • インフラのリソース使用状況に問題が起きていないか ◦ 定期的にメトリクスを確認することで上記のような異常がアラートして検知される前に出来るだけ対処する
41. • セキュリティ ◦ Lightsail を EC2 へ移行した話 ▪ アクセスキーを廃止し IAM ロールに置き換えることでキーが漏洩する可能性を最小限にした ◦ IAM ユーザの管理 ▪ Root ユーザでの運用をやめ、AWS SSO を使用したユーザ管理を行うようにした • モニタリング ◦ New Relic 導入の話 ▪ サービスが正常稼働していることを運営メンバーが把握できるようにアラートを設定 ▪ 定期的なパフォーマンスの観測会を行うことでユーザ体験の向上を目指す まとめ