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

by NobuakiKikuchi

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

自己紹介菊池宣明 ● 主に SRE 関係の仕事を担当 ● 今年からハッカー飯の開発メンバーとしてジョイン経歴 ● 科学系の大学院を卒業→ CIer（新卒） → 独立 ● エンジニア5年生趣味 ● ゲーム（スマブラ、Fortnite）好きな AWS サービス ● AWS サポート @kikulabo

Slide 3

Slide 3 text

ハッカー飯とは？技術や知識でアイデアを形にする人々(=ハッカー)が、ご飯を囲むような気軽さで、語り合い、教え合い、繋がれるオンラインプラットフォーム

Slide 4

Slide 4 text

● 会社概要 ○ 会社名：株式会社スタークロス ○ 代表取締役: 西田宗太郎 ● ハッカー飯の特徴 ○ 話したいことをもとにエンジニアと1 on 1マッチング ○ 複数人とエンジニアと簡易的なイベントを行う、食事会 ○ 興味のあることをもとに集まるコミュニティ機能 ● サービス開発の背景 ○ アイデアを形にするエンジニアが周りにいない ○ 他の企業に勤めてるエンジニアの生の声が知りたい ○ 技術雑談をして新しい発見をしたいなどなど、エンジニアと気軽に話せる環境が周りにあまりないといった課題を解決するためハッカー飯とは？

Slide 5

Slide 5 text

ハッカー飯の特徴

Slide 6

Slide 6 text

ハッカー飯の特徴

Slide 7

Slide 7 text

ハッカー飯の特徴

Slide 8

Slide 8 text

ハッカー飯の特徴

Slide 9

Slide 9 text

ハッカー飯の特徴

Slide 10

Slide 10 text

ハッカー飯の運営・開発について ● 運営に関して ○ メンバー全員それぞれ本業がある中、副業でハッカー飯に携わっている ● 開発スタイル ○ 毎週土曜日に Discord のボイスチャンネルに入室し各々開発を進めていく ○ 1時間開発して10分間休憩（スマブラ）をするというサイクルで行っている ○ 夜に定例を行いそれぞれのタスクの確認や今後の方針について話し合う ● 収益化に関して ○ 現状収益化がまだ出来ていないのでコストを抑えた構成となっている ○ 今後法人版のハッカー飯を作り、企業の中のエンジニアと気軽に繋がれるようなシステムを構築する予定

Slide 11

Slide 11 text

本日お話しする内容 ● セキュリティ ○ Lightsail を EC2 へ移行した話 ○ IAM ユーザの管理 ● モニタリング ○ New Relic 導入の話

Slide 12

Slide 12 text

本日お話しする内容 ● セキュリティ ○ Lightsail を EC2 へ移行した話 ○ IAM ユーザの管理 ● モニタリング ○ New Relic 導入の話

Slide 13

Slide 13 text

ハッカー飯のインフラ構成の概要（初期）

Slide 14

Slide 14 text

ハッカー飯のインフラ構成の概要（初期）

Slide 15

Slide 15 text

Lightsail とは？ https://aws.amazon.com/jp/lightsail/

Slide 16

Slide 16 text

Lightsail の選定した3つの理由 ● 理由①: コスト管理を行いやすいから ○ 定額で使用できるため予算を立てやすい ○ $3.5 のプランを使用すると EC2 の一番安いインスタンスタイプを選択して1ヶ月稼働した金額よりも安くなる

Slide 17

Slide 17 text

● 理由②: 環境の構築を簡単に素早く出来るから ○ 数クリックで環境を構築できるのは当時の開発メンバーにとって都合が良かった Lightsail の選定した3つの理由

Slide 18

Slide 18 text

Lightsail の選定した3つの理由 ● 理由③: EC2 への移行も可能 ○ Lightsail 上で取得したスナップショットを簡単に EC2 へエクスポートを行える

Slide 19

Slide 19 text

Lightsail を使っていて困ったこと ● Lightsail に IAM ロールを使用できない ○ EC2 のように必要な権限を付与した IAM ロールを作成してアタッチするといったことが出来ない ○ IAM ユーザを作成しアクセスキーをインスタンス内部に格納する必要がある ● スケールアップが簡単に出来ない ○ EC2 のようにインスタンスを停止しスケールアップして起動という操作が Lightsail では行えない ■ Lightsail の場合スケールアップするにはスナップショットから作り直す必要がある ○ 今後サービスが広く認知されアクセス数が増えた際に困りそう

Slide 20

Slide 20 text

Lightsail から EC2 へ移行 ● アクセスキー/シークレットキーがハードコーディングされており誰でも見れる状態になっていた ● 今後開発メンバーが増えてきた際にセキュリティ上リスクなると判断し、 IAM ロールを使用できる EC2 へ移行 ○ 移行の流れ 1. Lightsail を EC2 へエクスポート 2. 適切な権限に絞った IAM ロールを EC2 にアタッチ 3. 使用していたアクセスキーを無効化しテストを実施 4. 問題ないことを確認出来次第アクセスキーを削除

Slide 21

Slide 21 text

IAM ユーザの管理 ● AWS コンソールへのログイン等がこれまで Root ユーザで行われていた ● アクセスキーの使用を無くしたタイミングで IAM ユーザ管理の見直しを実施 ● ハッカー飯では簡単にセットアップできてユーザ管理を効率化出来る AWS Single Sign-On を採用

Slide 22

Slide 22 text

● AWS SSO を使用することでユーザー/グループの管理および認証を行える ○ ポータルサイトにログイン後、所属しているグループに付与されている権限のみ使用を制限を出来る AWS Single Sign-On（SSO）について

Slide 23

Slide 23 text

本日お話しする内容 ● セキュリティ ○ Lightsail を EC2 へ移行した話 ○ IAM ユーザの管理 ● モニタリング ○ New Relic 導入の話

Slide 24

Slide 24 text

監視導入の背景 ① ② ③ ④ .NET 5 から .NET 6 へバージョンを上げるぞ！ハッカー飯運営

Slide 25

Slide 25 text

監視導入の背景 ① ② ③ ④ .NET 5 から .NET 6 へバージョンを上げるぞ！ハッカー飯運営インフラ側の必要な作業を行わずに作業を終了

Slide 26

Slide 26 text

監視導入の背景 ① ② ③ ④ .NET 5 から .NET 6 へバージョンを上げるぞ！ハッカー飯にログイン出来ない人が発生ハッカー飯運営インフラ側の必要な作業を行わずに作業を終了

Slide 27

Slide 27 text

ユーザが連絡することで運営側が障害を認知監視導入の背景 ① ② ③ ④ .NET 5 から .NET 6 へバージョンを上げるぞ！インフラ側の必要な作業を行わずに作業を終了ハッカー飯にログイン出来ない人が発生ハッカー飯運営

Slide 28

Slide 28 text

● 反省点 ○ 必要な操作が本番環境で実施されていなかった ■ 改善点: 手順のレビュー制度の導入や Ansible 化を実施 ○ ハッカー飯が正常稼働しているかどうかをそもそも運営サイドが認知できていない ■ 改善点: モニタリングツールの導入 ● よりユーザ体験を向上させるためにモニタリングツールの導入を優先的に実施障害内容の振り返り

Slide 29

Slide 29 text

● CloudWatch と SaaS 製のモニタリングツール ○ どちらも出来ることは大方一緒（のはず）で、得意分野がそれぞれ異なる。 ○ CloudWatch ■ AWS リソースを手早くモニタリングすることが出来る ○ SaaS 監視ツール ■ マルチアカウント/クラウドの管理が得意 ● 将来的にマルチアカウント/クラウド化しても大丈夫なようにハッカー飯では SaaS 監視ツールを採用モニタリングツールの選定

Slide 30

Slide 30 text

New Relic について ● ハッカー飯では New Relic という SaaS 製の監視ツールを導入 ○ 選定理由: １ユーザであれば全ての機能を期間制限なく無料利用枠で使用できるため ■ ※月間100GBまでのデータ容量であれば無料（他にも制限は存在します） ● New Relic の主な機能 ○ Telemetry Data Platform ■ テレメトリデータを収集・格納する場所。チャートやダッシュボードを作成することも出来る。 ○ Full Stack Observability ■ 収集したテレメトリーデータを分析・可視化することが出来る機能。 ○ Alert and Applied Intelligence ■ 閾値ベースのアラート設定や、異常値の検出やインシデントの予測等を行う機能。

Slide 31

Slide 31 text

● ハッカー飯では New Relic という SaaS 製の監視ツールを導入 ○ 選定理由: １ユーザであれば全ての機能を期間制限なく無料利用枠で使用できるため ■ ※月間100GBまでのデータ容量であれば無料 ● New Relic の主な機能 ○ Telemetry Data Platform ■ テレメトリデータを収集・格納する場所。チャートやダッシュボードを作成することも出来る。 ○ Full Stack Observability ■ 収集したテレメトリーデータを分析・可視化することが出来る機能。 ○ Alert and Applied Intelligence ■ 閾値ベースのアラート設定や、異常値の検出やインシデントの予測等を行う機能。 New Relic についてメトリクス、イベント※、ログ、トレースのことを指す ※New Relic Agent が送信するデータ

Slide 32

Slide 32 text

Telemetry Data Platform について ● Agent をインストールすることでテレメトリーデータを Telemetry Data Platform に送信することが出来る ● テレメトリーデータを基にダッシュボードを作成することも可能

Slide 33

Slide 33 text

● New Relic APM ○ アプリケーションのパフォーマンスの計測を行える機能 Full Stack Observability について Webリクエストの処理に費やす平均時間

Slide 34

Slide 34 text

Full Stack Observability について ● New Relic APM ○ アプリケーションのパフォーマンスの計測を行える機能 1分間に処理するリクエストの数

Slide 35

Slide 35 text

Full Stack Observability について ● New Relic APM ○ アプリケーションのパフォーマンスの計測を行える機能

Slide 36

Slide 36 text

● Apdex Score について補足 ○ ユーザ満足度を定量的に表したもの ○ レスポンスタイムの閾値を T とした時、リクエストを以下の3つのレベルに分類 ■ <満足> レベルのリクエスト: レスポンスタイム ≦ T ■ <許容可能> レベルのリクエスト: T ＜レスポンスタイム ≦ 4T ■ <不満足> レベルのリクエスト: 4T ＜レスポンスタイム ○ リクエストを分類後、下記の計算式を用いて Apdex Score を算出 ■ 0～1 の値を取り、0が最悪のスコア、1が最高のスコアとなる Full Stack Observability について

Slide 37

Slide 37 text

Full Stack Observability について ● New Relic Infrastructure ○ CPU、メモリ、ディスク IO やネットワークトラフィックを観測することも出来る

Slide 38

Slide 38 text

Full Stack Observability について ● New Relic Synthetics ○ システムに対して外部から稼働状況を確認する機能（外形監視）

Slide 39

Slide 39 text

Alert and Applied Intelligence について ● New Relic Alert ○ アラートの設定および通知先（Email、Slack、PagerDuty 等）を設定する機能

Slide 40

Slide 40 text

New Relic 使って実践していること ● ユーザに影響が出そうなものをアラートとして設定 ○ 外型監視、エラー発生率、レスポンスタイム等 ● 1週間に一度メトリクス全体を一通り確認 ○ アラートが発生していなくとも異常が発生していないかを確認するため ■ 確認ポイント ● エラーが起きていないか ● レスポンスタイムに異常が起きていないか ● インフラのリソース使用状況に問題が起きていないか ○ 定期的にメトリクスを確認することで上記のような異常がアラートして検知される前に出来るだけ対処する

Slide 41

Slide 41 text

● セキュリティ ○ Lightsail を EC2 へ移行した話 ■ アクセスキーを廃止し IAM ロールに置き換えることでキーが漏洩する可能性を最小限にした ○ IAM ユーザの管理 ■ Root ユーザでの運用をやめ、AWS SSO を使用したユーザ管理を行うようにした ● モニタリング ○ New Relic 導入の話 ■ サービスが正常稼働していることを運営メンバーが把握できるようにアラートを設定 ■ 定期的なパフォーマンスの観測会を行うことでユーザ体験の向上を目指すまとめ