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

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

Transcript

1. ヤプリのSREにおけるセキュリティ強化の
   取り組みを公開する
   〜上場前後の変化〜
   

   View Slide

2. #srenext
   2018/01にQAエンジニアとしてノーコードでアプリ開発を実現
   するYappliを提供する株式会社ヤプリにジョイン
   QAの立ち上げやテスト自動化推進などを経てSREに転身
   現在は基盤部の責任者として、全社のセキュリティ強化をミッ
   ションとして各種対策を推進
   基盤部
   └ SREグループ：Yappliのサービス・インフラ
   └ ITグループ（情シス）：社内IT全般・情報セキュリティ
   自己紹介
   望月　真仁
   (もちづき　まさひと)
   テックブログの編集長もやっております
   ヤプリの技術にご興味がある方は是非ご覧ください
   https://tech.yappli.io/
   

   View Slide

3. #srenext
   SREとしてセキュリティに興味があるものの、具体
   的に何をしたら良いか迷っている方が、
   一歩先に進めるようなヒントを得ていただく
   今日のゴール
   

   View Slide

4. #srenext
   1. 上場に向けたセキュリティ強化
   2. 上場後のセキュリティ推進
   3. 新たな課題への挑戦
   4. 最後に（まとめ・補足）
   アジェンダ
   

   View Slide

5. 1
   上場に向けたセキュリティ強化
   

   View Slide

6. #srenext
   私がSREに転身したあたりから、社内で上場というワードが（現実的な意味合いで）ちら
   ほら話題にあがり始める
   経理や監査とか大変そうだなあ
   でも開発は別に関係ないでしょ
   上場・・・？
   →関係あった
   

   View Slide

7. #srenext
   上場に向けてサービスや社内ITの具体的なチェック項目やリクエストが出てくる
   →サーバー・SRE・情シスにてそれぞれ現状を整理して対応を行うことになった
   色々とチェックされる
   システムの権限はどうなっているか ✅
   データには誰がどうやってアクセスしているか ✅
   ログはどう管理しているか ✅
   端末は資産管理ツール等で一元管理されているか ✅
   退職者のアカウントは確実に削除されているか ✅
   端末紛失時の情報漏洩対策はどうなっているか ✅
   個人情報はどう管理しているか ✅
   

   View Slide

8. #srenext
   【指摘】
   売上請求の元となる課金関連データに対して、複数人の開発メンバーがアクセス・変更
   できる権限を付与されている
   →不正に改ざんすることができ得る
   ＊そもそも1つのデータベースユーザーを、色々なサービスや人間で共用していた
   開発的に影響が大きかった対応
   

   View Slide

9. #srenext
   【実際の対応イメージ】
   ● サービスが利用するDBユーザーと、人間が利用するDBユーザーを分ける
   ● 該当サービスに必要な権限のみ付与する
   ● データ変更は人間ではなくシステム的なバッチのみ許容する
   また適切なワークフローを経て実行可能とする
   開発的に影響が大きかった対応
   

   View Slide

10. #srenext
    結果、かなりの労力が必要となった
    ● 計画・設計・影響度調査
    ● 各サービスごとのDB接続を設定し直し
    （ハードコーディングされているケースも・・・）
    ● 認証情報はenv等を見て悪用できないよう管理サービスに委託
    ● インフラコード化されていなかった部分を対応
    ● 事故が起きないようきちんとQAプロセスを通過
    ● 人間は業務に直接的な影響が出ないよう徐々に締め出し
    開発的に影響が大きかった対応
    

    View Slide

11. #srenext
    ● 普段からセキュリティを意識していないと、現状把握するだけでもかなり工数・手間
    がかかる
    ● 対応・対策を検討するのもセキュリティの知見がないと苦労する
    ● 上場のような大きなイベントに迫られると、スケジュール・プレッシャーなど大変
    ● 一方で会社的にはセキュリティがフォーカスされる良い機会となった
    （株主・取引先・世間からの関心、経営陣の意識、エンジニアのやる気）
    振り返り
    

    View Slide

12. #srenext
    ● 全社に向けたセキュリティ研修
    ● JamfによるMacの統合管理
    ● Googleをベースとしたアカウント管理
    ● PCのディスク保護
    ● ライセンス管理の透明化
    情シスも頑張った
    

    View Slide

13. 2
    上場後のセキュリティ推進
    

    View Slide

14. 上場をきっかけに会社全体でセキュリティへの注目が高まる
    →SREでセキュリティやるぞ！
    →AWSを中心にセキュリティ対策をどんどん推進した
    セキュリティ推進
    

    View Slide

15. #srenext
    ● Amazon GuardDuty
    ○ 不正なアクティビティだけでなく、副次的に権限の設定ミスなども気づけるように
    ● AWS WAF
    ○ 近年お客様から特に要求が多く、堂々とセキュリティチェックに回答できるように
    ● PHP5撲滅委員会
    ○ セキュリティだけでなく、パフォーマンスも向上
    ● ウィルス対策
    ○ 安心感、WAF同様セキュリティチェックでよくチェックされていた
    ● ディスク・データ暗号化
    ○ 流出・漏洩時のダメージ軽減
    ● 第三者による定期的な脆弱性診断
    ○ お墨付き、またトレンドを踏まえて今対策すべき箇所がずばり特定できるように
    効果的だったセキュリティ対策
    

    View Slide

16. #srenext
    一方でやってみたものの、まだうまく効果が出せていないものも
    ● Amazon Inspector
    ○ 検出はできたものの優先度が効率的に管理できていない
    ● Amazon Detective
    ○ コストが負担に
    ● Security Command Center(Google Cloud)
    ○ 検出はできたものの Google Cloudの対応自体が後回しになりがち
    ● MFA(IAM)
    ○ これ自体はもちろん有効である一方、すぐに後述の Single Sign-Onにてリプレイス
    活用できていないセキュリティ対策
    

    View Slide

17. #srenext
    ここでふと思った
    ゴール
    ここ？
    󰣯
    ここ？
    󰣯
    ここ？
    󰣯
    我々のセキュリティはどこに向かっていて、今どのレベルなのか？
    そもそもゴールとは？
    

    View Slide

18. #srenext
    ● 進め方は適切なのか？
    ○ 目についたものをやる
    ○ セキュリティチェックシートでよく言われるものをやる
    ● うまく運用できたものと、できなかったものの違いは何か？
    ● そもそもその対策は本当にやるべきだったのか？
    ● セキュリティ対策だからという理由で他タスクより優先すべきだったか？
    といった問いに自分自身が答えられなかった
    振り返り
    

    View Slide

19. #srenext
    整理してみよう！
    整理・可視化
    セキュリティ項目 対策内容
    監査ログ AWS CloudTrailで記録
    脅威の検出 Amazon GuardDutyで監視
    ソフトウェアの脆弱性 Amazon Inspectorで検出
    ・・・ ・・・
    

    View Slide

20. #srenext
    やったこと・知っていることベースなので抜け漏れが出る
    整理・可視化
    セキュリティ項目 対策内容
    監査ログ AWS CloudTrailで記録
    脅威の検出 Amazon GuardDutyで監視
    ソフトウェアの脆弱性 Amazon Inspectorで検出
    ・・・ ・・・
    ↑この項目で十分か？ ↑他に考慮すべき点はないか？
    

    View Slide

21. #srenext
    SREメンバー「AWS Well-Architected（セキュリティの柱）を使って振り返りをしてみませ
    ん？」
    AWS Well-Architected
    

    View Slide

22. #srenext
    現在の位置や自社の傾向が見えてきた
    ● 🆗権限管理は結構できてきていた
    ● ワークロードの管理が弱い🤔
    ● 🆗データはきちんと分類できている
    一方で取り扱い・保護はもう一歩進めたい🤔
    ● 実際にインシデントが発生したときの動きがあまり整備できていない🤔
    ● 情報収集があまりできていない🤔
    AWS Well-Architected
    

    View Slide

23. #srenext
    AWS Well-Architected
    振り返りをすること自体にも意味があった
    ● チーム全体でセキュリティに取り組むという雰囲気作りができた👍
    ● 他メンバーのセキュリティに関する考え方や情報が共有できた👍
    同じ項目でも人によってOKになったりNGになったりするのが興味深い
    ● 自身があまり担当してこなかったインフラ・セキュリティ領域の知見が得られた👍
    ● フレームワークに沿った定形の記録に残すことで、後から振り返りがしやすい👍
    次回実施した際に比較検討ができ、モチベーションになる（成長を実感！）
    

    View Slide

24. #srenext
    ある日AWSのSAさんとお話しする機会があって、セキュリティ対策をどう進めるかにつ
    いて情報交換した
    →他のフレームワーク、例えばISMSとAWSのセキュリティ対策をマッピングして整理し
    てみるというやり方もありますよ
    →それ良さそう！
    （ちょうどISMSを取得しようとしているタイミングであったが、認証を取得することが目的
    ではなく、実務にうまくリンクしてPDCAを回せるように手を打ちたいという思いがあった）
    別角度でも整理
    

    View Slide

25. #srenext
    ISMS
    AWS Well-Architectedだとレビューしきれなかった実務レベルでの対策や改善も見えて
    きた
    当時のマッピング図（抜粋）
    

    View Slide

26. #srenext
    結果
    ゴール
    ここ
    󰣯
    インシデントを起こさないセキュアなサービス・体制
    ISMSやAWS Well-Architected
    などの道筋
    

    View Slide

27. #srenext
    セキュリティというキーワードが先行しすぎて、対策すること自体が目的となってしまった
    →「何のためにそのセキュリティ対策をするのか」が曖昧なため、効果があまり出せてい
    なかった
    →きちんと振り返ってPDCAサイクルを回して改善することで徐々に効果的な対策となっ
    てきている
    ヤプリのセキュリティ取り組みにおける反省点
    

    View Slide

28. #srenext
    Amazon GuardDuty入れるぞ！
    （あまりよく分かっていないけど良いらしい）
    →イベント発生しても誰も気づかなかった
    ＊AWSコンソールでは出ているが、そもそもコンソールに入らない日もあるし、入っても
    気づかないことは多々ある
    例えばAmazon GuardDutyで実際にあった話
    

    View Slide

29. #srenext
    Slack通知するぞ！
    →何が発生しているかよく分からずスルーされてしまうことも
    例えばAmazon GuardDutyで実際にあった話
    

    View Slide

30. #srenext
    ちゃんと何があったか分かるようにしよう！
    ヤプリテックブログ参照
    インターン生がGuardDutyのSlack通知を改善してみた！
    例えばAmazon GuardDutyで実際にあった話
    

    View Slide

31. #srenext
    ある日気づいた
    全てのAWSアカウントで有効になってないじゃん・・・
    例えばAmazon GuardDutyで実際にあった話
    →次章へ
    

    View Slide

32. 3
    新たな課題への挑戦
    

    View Slide

33. #srenext
    ● 新しく作ったAWSアカウントで、既存と同じレベルのセキュリティ対策ができていな
    い
    ● 特定のサービスでは対策できているが、別のサービスではできていない
    （歴史的経緯や流行にのって色々なインフラがある）
    ● SREがインフラ構築しないケースで穴があった
    新たな課題
    

    View Slide

34. #srenext
    これまで整理した表形式の縦横にプラスして、対象となるAWSアカウントやサービスな
    どの奥行きも管理すべき
    かつ手動・目視では限界が来るのでシステム化・自動化したい
    奥行きも管理
    対策項目
    対策状況
    適用対象
    （アカウント毎、サービス毎など）
    

    View Slide

35. #srenext
    ● AWS Single Sign-On(with Okta)
    ○ OktaからSSO＆Provisioning、AWSアカウントをまたいで入退社も自動管理
    ● AWS Organizations
    ○ CloudTrail・GuardDuty等の一元管理、Single Sign-Onと連携したアクセス・ポリシー管理
    ● AWS Control Tower
    ○ 発見的ガードレールの導入（ ←今ここ）
    直近で取り組んでいること
    

    View Slide

36. #srenext
    入退社や異動などのイベントをトリガに、AWSアカウントを含む各サービスアカウントの
    メンテナンスを自動化
    AWS Single Sign-OnとOktaを組み合わせたアカウント・権限管理
    

    View Slide

37. #srenext
    AWS Single Sign-OnとOktaを組み合わせたアカウント・権限管理
    Okta
    (IdP)
    Kintone
    (社員DB) Zapier
    AWS
    アカウント
    (SSO)
    SCIM
    AWS
    アカウント1
    AWS
    アカウント2
    AWS
    アカウント3
    対象アカウント
    ・PermissionSetなど
    CloudFormationで管理
    

    View Slide

38. #srenext
    SRE・情シスの双方でさまざまな効果が！
    ● 人事イベントのたびに手動でアカウント作成したり削除したりが不要に
    ● AWSアカウントが増えてきたが抜け漏れなく管理
    ● 権限の一元管理
    ● 定期的な棚卸しが不要に
    ● MFAなど認証ポリシーをOktaで統合管理
    AWS Single Sign-OnとOktaを組み合わせたアカウント・権限管理
    →SRE・情シスの共同成果！
    

    View Slide

39. 4
    最後に
    

    View Slide

40. #srenext
    ● 上場のような大きなイベントを迎える前から、セキュリティにもアンテナをはっておけ
    ば良かった
    ● 自分たちのセキュリティがどこを目指していて、今どのレベルにあるのか可視化し
    ておくとその後の行動・判断がしやすい
    ● なんのためにその対策をするのか、目的を明確化した上で実施すると効果が出や
    すい
    ● （一方でまずえいやでやってしまってから、振り返りをして改善していくサイクルを後
    づけで整備する形も意外とありかも）
    まとめ
    

    View Slide

41. #srenext
    ● 情シス部門と仲良く（密にコミュニケーション）しておくと良い
    ○ OktaをベースにしたSingle Sign-Onでは色々協力してもらった
    ○ 担当領域のセキュリティ情報を共有しあえる
    ● セキュリティチェックシートは目を通しておいた方が良い
    ○ 取引しているユーザーが求めているレベル感やトレンドが把握できる
    ○ 製品・サービス観点でセキュリティ系の機能を実装する際の参考になる
    ● セキュリティを誰が主導するのか会社としてメッセージングしておくと良い
    ○ セキュリティをミッションとした基盤部の立ち上げ
    ○ セキュリティ関連の相談や情報や課題がどんどん集まってきた
    （今まで君たちどこにいたの？）
    補足
    

    View Slide

42. 5
    本当に最後に
    

    View Slide

43. #srenext
    セキュリティエンジニアさん・セキュリティやりたいSREさん絶賛募集中
    https://open.talentio.com/r/1/c/yappli/pages/48798
    https://www.wantedly.com/projects/577875
    宣伝させてください🙏
    

    View Slide