[SRE NEXT 2022]ヤプリのSREにおけるセキュリティ強化の取り組みを公開する

https://sre-next.dev/2022/schedule#jp05

Transcript

1. ヤプリのSREにおけるセキュリティ強化の 取り組みを公開する 〜上場前後の変化〜
2. #srenext 2018/01にQAエンジニアとしてノーコードでアプリ開発を実現 するYappliを提供する株式会社ヤプリにジョイン QAの立ち上げやテスト自動化推進などを経てSREに転身 現在は基盤部の責任者として、全社のセキュリティ強化をミッ ションとして各種対策を推進 基盤部 └ SREグループ：Yappliのサービス・インフラ └ ITグループ（情シス）：社内IT全般・情報セキュリティ 自己紹介 望月　真仁 (もちづき　まさひと) テックブログの編集長もやっております ヤプリの技術にご興味がある方は是非ご覧ください https://tech.yappli.io/
3. #srenext SREとしてセキュリティに興味があるものの、具体 的に何をしたら良いか迷っている方が、 一歩先に進めるようなヒントを得ていただく 今日のゴール
4. #srenext 1. 上場に向けたセキュリティ強化 2. 上場後のセキュリティ推進 3. 新たな課題への挑戦 4. 最後に（まとめ・補足） アジェンダ
5. 1 上場に向けたセキュリティ強化
6. #srenext 私がSREに転身したあたりから、社内で上場というワードが（現実的な意味合いで）ちら ほら話題にあがり始める 経理や監査とか大変そうだなあ でも開発は別に関係ないでしょ 上場・・・？ →関係あった
7. #srenext 上場に向けてサービスや社内ITの具体的なチェック項目やリクエストが出てくる →サーバー・SRE・情シスにてそれぞれ現状を整理して対応を行うことになった 色々とチェックされる システムの権限はどうなっているか ✅ データには誰がどうやってアクセスしているか ✅ ログはどう管理しているか ✅ 端末は資産管理ツール等で一元管理されているか ✅ 退職者のアカウントは確実に削除されているか ✅ 端末紛失時の情報漏洩対策はどうなっているか ✅ 個人情報はどう管理しているか ✅
8. #srenext 【指摘】 売上請求の元となる課金関連データに対して、複数人の開発メンバーがアクセス・変更 できる権限を付与されている →不正に改ざんすることができ得る ＊そもそも1つのデータベースユーザーを、色々なサービスや人間で共用していた 開発的に影響が大きかった対応
9. #srenext 【実際の対応イメージ】 • サービスが利用するDBユーザーと、人間が利用するDBユーザーを分ける • 該当サービスに必要な権限のみ付与する • データ変更は人間ではなくシステム的なバッチのみ許容する また適切なワークフローを経て実行可能とする 開発的に影響が大きかった対応
10. #srenext 結果、かなりの労力が必要となった • 計画・設計・影響度調査 • 各サービスごとのDB接続を設定し直し （ハードコーディングされているケースも・・・） • 認証情報はenv等を見て悪用できないよう管理サービスに委託 • インフラコード化されていなかった部分を対応 • 事故が起きないようきちんとQAプロセスを通過 • 人間は業務に直接的な影響が出ないよう徐々に締め出し 開発的に影響が大きかった対応
11. #srenext • 普段からセキュリティを意識していないと、現状把握するだけでもかなり工数・手間 がかかる • 対応・対策を検討するのもセキュリティの知見がないと苦労する • 上場のような大きなイベントに迫られると、スケジュール・プレッシャーなど大変 • 一方で会社的にはセキュリティがフォーカスされる良い機会となった （株主・取引先・世間からの関心、経営陣の意識、エンジニアのやる気） 振り返り
12. #srenext • 全社に向けたセキュリティ研修 • JamfによるMacの統合管理 • Googleをベースとしたアカウント管理 • PCのディスク保護 • ライセンス管理の透明化 情シスも頑張った
13. 2 上場後のセキュリティ推進
14. 上場をきっかけに会社全体でセキュリティへの注目が高まる →SREでセキュリティやるぞ！ →AWSを中心にセキュリティ対策をどんどん推進した セキュリティ推進
15. #srenext • Amazon GuardDuty ◦ 不正なアクティビティだけでなく、副次的に権限の設定ミスなども気づけるように • AWS WAF ◦ 近年お客様から特に要求が多く、堂々とセキュリティチェックに回答できるように • PHP5撲滅委員会 ◦ セキュリティだけでなく、パフォーマンスも向上 • ウィルス対策 ◦ 安心感、WAF同様セキュリティチェックでよくチェックされていた • ディスク・データ暗号化 ◦ 流出・漏洩時のダメージ軽減 • 第三者による定期的な脆弱性診断 ◦ お墨付き、またトレンドを踏まえて今対策すべき箇所がずばり特定できるように 効果的だったセキュリティ対策
16. #srenext 一方でやってみたものの、まだうまく効果が出せていないものも • Amazon Inspector ◦ 検出はできたものの優先度が効率的に管理できていない • Amazon Detective ◦ コストが負担に • Security Command Center(Google Cloud) ◦ 検出はできたものの Google Cloudの対応自体が後回しになりがち • MFA(IAM) ◦ これ自体はもちろん有効である一方、すぐに後述の Single Sign-Onにてリプレイス 活用できていないセキュリティ対策
17. #srenext ここでふと思った ゴール ここ？ 󰣯 ここ？ 󰣯 ここ？ 󰣯 我々のセキュリティはどこに向かっていて、今どのレベルなのか？ そもそもゴールとは？
18. #srenext • 進め方は適切なのか？ ◦ 目についたものをやる ◦ セキュリティチェックシートでよく言われるものをやる • うまく運用できたものと、できなかったものの違いは何か？ • そもそもその対策は本当にやるべきだったのか？ • セキュリティ対策だからという理由で他タスクより優先すべきだったか？ といった問いに自分自身が答えられなかった 振り返り
19. #srenext 整理してみよう！ 整理・可視化 セキュリティ項目 対策内容 監査ログ AWS CloudTrailで記録 脅威の検出 Amazon GuardDutyで監視 ソフトウェアの脆弱性 Amazon Inspectorで検出 ・・・ ・・・
20. #srenext やったこと・知っていることベースなので抜け漏れが出る 整理・可視化 セキュリティ項目 対策内容 監査ログ AWS CloudTrailで記録 脅威の検出 Amazon GuardDutyで監視 ソフトウェアの脆弱性 Amazon Inspectorで検出 ・・・ ・・・ ↑この項目で十分か？ ↑他に考慮すべき点はないか？
21. #srenext SREメンバー「AWS Well-Architected（セキュリティの柱）を使って振り返りをしてみませ ん？」 AWS Well-Architected
22. #srenext 現在の位置や自社の傾向が見えてきた • 🆗権限管理は結構できてきていた • ワークロードの管理が弱い🤔 • 🆗データはきちんと分類できている 一方で取り扱い・保護はもう一歩進めたい🤔 • 実際にインシデントが発生したときの動きがあまり整備できていない🤔 • 情報収集があまりできていない🤔 AWS Well-Architected
23. #srenext AWS Well-Architected 振り返りをすること自体にも意味があった • チーム全体でセキュリティに取り組むという雰囲気作りができた👍 • 他メンバーのセキュリティに関する考え方や情報が共有できた👍 同じ項目でも人によってOKになったりNGになったりするのが興味深い • 自身があまり担当してこなかったインフラ・セキュリティ領域の知見が得られた👍 • フレームワークに沿った定形の記録に残すことで、後から振り返りがしやすい👍 次回実施した際に比較検討ができ、モチベーションになる（成長を実感！）
24. #srenext ある日AWSのSAさんとお話しする機会があって、セキュリティ対策をどう進めるかにつ いて情報交換した →他のフレームワーク、例えばISMSとAWSのセキュリティ対策をマッピングして整理し てみるというやり方もありますよ →それ良さそう！ （ちょうどISMSを取得しようとしているタイミングであったが、認証を取得することが目的 ではなく、実務にうまくリンクしてPDCAを回せるように手を打ちたいという思いがあった） 別角度でも整理
25. #srenext ISMS AWS Well-Architectedだとレビューしきれなかった実務レベルでの対策や改善も見えて きた 当時のマッピング図（抜粋）
26. #srenext 結果 ゴール ここ 󰣯 インシデントを起こさないセキュアなサービス・体制 ISMSやAWS Well-Architected などの道筋
27. #srenext セキュリティというキーワードが先行しすぎて、対策すること自体が目的となってしまった →「何のためにそのセキュリティ対策をするのか」が曖昧なため、効果があまり出せてい なかった →きちんと振り返ってPDCAサイクルを回して改善することで徐々に効果的な対策となっ てきている ヤプリのセキュリティ取り組みにおける反省点
28. #srenext Amazon GuardDuty入れるぞ！ （あまりよく分かっていないけど良いらしい） →イベント発生しても誰も気づかなかった ＊AWSコンソールでは出ているが、そもそもコンソールに入らない日もあるし、入っても 気づかないことは多々ある 例えばAmazon GuardDutyで実際にあった話
29. #srenext Slack通知するぞ！ →何が発生しているかよく分からずスルーされてしまうことも 例えばAmazon GuardDutyで実際にあった話
30. #srenext ちゃんと何があったか分かるようにしよう！ ヤプリテックブログ参照 インターン生がGuardDutyのSlack通知を改善してみた！ 例えばAmazon GuardDutyで実際にあった話
31. #srenext ある日気づいた 全てのAWSアカウントで有効になってないじゃん・・・ 例えばAmazon GuardDutyで実際にあった話 →次章へ
32. 3 新たな課題への挑戦
33. #srenext • 新しく作ったAWSアカウントで、既存と同じレベルのセキュリティ対策ができていな い • 特定のサービスでは対策できているが、別のサービスではできていない （歴史的経緯や流行にのって色々なインフラがある） • SREがインフラ構築しないケースで穴があった 新たな課題
34. #srenext これまで整理した表形式の縦横にプラスして、対象となるAWSアカウントやサービスな どの奥行きも管理すべき かつ手動・目視では限界が来るのでシステム化・自動化したい 奥行きも管理 対策項目 対策状況 適用対象 （アカウント毎、サービス毎など）
35. #srenext • AWS Single Sign-On(with Okta) ◦ OktaからSSO＆Provisioning、AWSアカウントをまたいで入退社も自動管理 • AWS Organizations ◦ CloudTrail・GuardDuty等の一元管理、Single Sign-Onと連携したアクセス・ポリシー管理 • AWS Control Tower ◦ 発見的ガードレールの導入（ ←今ここ） 直近で取り組んでいること
36. #srenext 入退社や異動などのイベントをトリガに、AWSアカウントを含む各サービスアカウントの メンテナンスを自動化 AWS Single Sign-OnとOktaを組み合わせたアカウント・権限管理
37. #srenext AWS Single Sign-OnとOktaを組み合わせたアカウント・権限管理 Okta (IdP) Kintone (社員DB) Zapier AWS アカウント (SSO) SCIM AWS アカウント1 AWS アカウント2 AWS アカウント3 対象アカウント ・PermissionSetなど CloudFormationで管理
38. #srenext SRE・情シスの双方でさまざまな効果が！ • 人事イベントのたびに手動でアカウント作成したり削除したりが不要に • AWSアカウントが増えてきたが抜け漏れなく管理 • 権限の一元管理 • 定期的な棚卸しが不要に • MFAなど認証ポリシーをOktaで統合管理 AWS Single Sign-OnとOktaを組み合わせたアカウント・権限管理 →SRE・情シスの共同成果！
39. 4 最後に
40. #srenext • 上場のような大きなイベントを迎える前から、セキュリティにもアンテナをはっておけ ば良かった • 自分たちのセキュリティがどこを目指していて、今どのレベルにあるのか可視化し ておくとその後の行動・判断がしやすい • なんのためにその対策をするのか、目的を明確化した上で実施すると効果が出や すい • （一方でまずえいやでやってしまってから、振り返りをして改善していくサイクルを後 づけで整備する形も意外とありかも） まとめ
41. #srenext • 情シス部門と仲良く（密にコミュニケーション）しておくと良い ◦ OktaをベースにしたSingle Sign-Onでは色々協力してもらった ◦ 担当領域のセキュリティ情報を共有しあえる • セキュリティチェックシートは目を通しておいた方が良い ◦ 取引しているユーザーが求めているレベル感やトレンドが把握できる ◦ 製品・サービス観点でセキュリティ系の機能を実装する際の参考になる • セキュリティを誰が主導するのか会社としてメッセージングしておくと良い ◦ セキュリティをミッションとした基盤部の立ち上げ ◦ セキュリティ関連の相談や情報や課題がどんどん集まってきた （今まで君たちどこにいたの？） 補足
42. 5 本当に最後に
43. #srenext セキュリティエンジニアさん・セキュリティやりたいSREさん絶賛募集中 https://open.talentio.com/r/1/c/yappli/pages/48798 https://www.wantedly.com/projects/577875 宣伝させてください🙏