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

by Masahito Mochizuki

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

3 新たな課題への挑戦

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

4 最後に

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

5 本当に最後に

Slide 43

Slide 43 text

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