セキュリティ研修〜マネジメントパート〜（サイバーエージェント新卒研修2024）

24新卒エンジニア向け  セキュリティ研修  ～マネジメントパート～  2024/4 

はじめに  新入社員のみなさん  入社おめでとうございます🎉  

自己紹介  アシスタントの皆さんパーくん楽天家でドーナツ好きな男の子宇宙人に狙われているパーにゃん明るくノリの良いバリキャリ女子パーくん憧れの先輩らしい

自己紹介  アシスタントの皆さんパーマン通称「情報セキュリティ博士」イギリス出身のジェントルメンワームくんサイバー攻撃で地球侵略を目論む見た目に違わず The 地球外生命体

はじめに          本パートの目的 

はじめに  情報セキュリティの全体像を知る 

はじめに  エンジニアと情報セキュリティ  セキュリティのルール作ったよ！  開発のセキュリティ基準作ったよ！  リーダー開発者

はじめに  エンジニアと情報セキュリティ  セキュリティのルール作ったよ！  開発のセキュリティ基準作ったよ！  リーダー開発者セキュリティのルール守るよ！  開発のセキュリティ基準に従うよ！ 

9 リーダー開発者正直、理由はよくわかんないけど  とりあえず言われたとおりにやろう 

10 これでは、もったいないリーダー開発者正直、理由はよくわかんないけど  とりあえず言われたとおりにやろう 

はじめに  とは言え、いきなり  あれもこれも覚えるのは無理なので… 

はじめに  情報セキュリティを理解するための  ハコ（全体像）を押さえましょう 

はじめに          そもそもサイバーエージェントにおける  「エンジニア」の仕事とは？ 

はじめに  社会で広く利用されているサイバーエージェントの  サービスを開発する仕事です 

15 安心安全なサービスを維持しないと。。。            　　　　数多くの人間に被害を与えてしまいます 

16 サービス利用者の「個人情報」が漏れると、、、 • アカウントの乗っ取り・なりすまし • 悪徳商法・ストーカー・脅しのネタに悪用される • ダークウェブ（闇のEC）で取引される想像以上の被害に発展する可能性がありますなんで私の今いる場所が 
バレてるの！？怖いよ... 

17 会社との契約で「漏らしてはいけない」情報が漏れると、、、 • 取引先、ユーザー、株主の信用を失ってしまう • 漏らした情報を悪用されて損害を発生させてしまう巨額の損害に発展する可能性があります大丈夫って言うから情報を預けたのに…  もう一緒に仕事しないぞ！！ 

18 社会に大きな影響を与える＝ネガティブな影響も与えうる  • 炎上する  • ユーザーが激減する  • 法的責任を問われる 
• 今後の新サービスにネガティブな影響を及ぼす　など    事業を続けることが困難になりかねない。 

はじめに  どんなに良いサービスでも    ひとつのセキュリティ事故で消し飛ぶ可能性があります 

はじめに  サイバーエージェントでは、ビジネスに  直結するリスクを「一発アウト」と呼んでいます 

はじめに  「不安」「心配」で思考停止せずに  情報セキュリティの枠組みを知り  「一発アウト」のリスクに  アンテナを張れるようになりましょう 

情報セキュリティ概要

情報セキュリティとは  全体像が分からないと考えようがないそもそも、どこから何を考えたらいんだろう...？

情報セキュリティとは  まずは手堅く  「情報セキュリティ」の  定義から確認しましょう 

情報セキュリティとは  各産業の標準化などを進めている組織  「JISC(日本産業標準調査会)」を当たってみます   

情報セキュリティとは JIS Q 27000:2019の定義  3.28   情報セキュリティ（information security）   情報の機密性（3.10）、完全性（3.36）及び可用性（3.7）を 
維持すること。     さらに，真正性（3.6），責任追跡性，否認防止（3.48），信頼性（3.55）などの特性を維持することを含めることもある。 

情報セキュリティとは  ざっくり言ってしまえば、  • 機密性  • 完全性  • 可用性  の３要素を維持できていないと 
　　　情報セキュリティではないようです   

情報セキュリティとは  とは言え、これでは  まだちょっとよく分かりません 

情報セキュリティとは  そこで次に  ３要素の定義を確認してみましょう 

情報セキュリティとは  先にざっくり言ってしまうと、下記のようになります。    • 機密性　＝　漏らさない  • 完全性　＝　改ざんされていない  • 可用性　＝　いつでも使えるようにする   
これを念頭に置いて定義を確認します。 

機密性(Confidentiality)  認可されていない個人、エンティティ又はプロセスに対して、  情報を使用させず、また、開示しない特性。      「認可」については、後ほど掘り下げましょう。  情報セキュリティとは 

エンティティ？プロセス？情報セキュリティとは 

情報資産にアクセスするのは  人間だけとは限りません  管理者 SIEMサービス人力でもログを見ることもできるログ情報にアクセスアラート発報このため「エンティティ」と 
表現する必要があります  情報セキュリティとは  システム内のログ情報

完全性(Integrity)  正確さ及び完全さの特性。      完全性のみ損なうケースとして、例えば、  ・認可された人間による内部犯行、  ・認可されたエンティティによる誤操作  などが考えられます。  情報セキュリティとは 

可用性(Availability) 認可されたエンティティが要求したときに、アクセス及び使用が可能である特性。可用性を度外視して機密性・完全性に振り切ると、業務の利便性を損なう恐れがあります。    そうなると、正規の手順を飛ばすなどの脱法行為やシャドーIT等の問題を招く可能性があり、  結果的に機密性や完全性を損なう事態に至ることがあります。 
情報セキュリティとは 

• 機密性（Confidentiality）  • 完全性（Integrity）  • 可用性（Availability）  完全性  Integrity  機密性  Confidentiality 
可用性  Availability  情報セキュリティ3要素  CIA  これらを脅かすものから情報資産を  守ることが情報セキュリティの  基本的な考え方です    情報セキュリティを保つことは、  ビジネス（事業）を継続するうえで、  とても大切なポイントになります。  情報セキュリティとは 

【機密性】識別・認証・認可とは

【機密性】識別・認証・認可とは「機密性」について少し掘り下げましょう。    ▪ 機密性のおさらい  認可されていない個人、エンティティ又はプロセスに対して、  情報を使用させず、また、開示しない特性。 

認可に至るまでのステップは下記のとおりです。    1. 識別  2. 認証  3. 認可    【機密性】識別・認証・認可とは

まずはそれぞれの定義を確認しましょう    1. 識別  ◦ ユーザーがシステムに対して自分が誰か宣言すること  2. 認証  ◦ システムがそのユーザーが宣言した人物か確認すること 
3. 認可  ◦ 認証されたユーザーがシステムの特定のリソースにアクセスすることを許可すること    【参考】 • NIST SP 800-63 • RFC4949

マンションの部屋を借りる場面で例えてみます。  地球侵略の足掛かりに部屋を借りるぜ！  【機密性】識別・認証・認可とは

機密性に関する情報セキュリティ対策の例「認可」に至るまでのステップ 

機密性に関する情報セキュリティ対策の例「認可」に至るまでのステップ  ①識別契約で部屋を借りる宣言をする 103号室はワームくんが使う

機密性に関する情報セキュリティ対策の例「認可」に至るまでのステップ  ①識別 ➁認証鍵を持ってマンションに入る鍵があるから本人だろう契約で部屋を借りる宣言をする
103号室はワームくんが使う

機密性に関する情報セキュリティ対策の例「認可」に至るまでのステップ  ①識別 ➁認証 ③認可借主が借りている部屋に入るワームくんは 103号室なら入れる契約で部屋を借りる宣
言をする 103号室はワームくんが使う鍵を持ってマンションに入る鍵があるから本人だろう

機密性に関する情報セキュリティ対策の例 ①識別が無いと、➁認証で弾かれる  ①識別 ➁認証賃貸借契約で部屋を借りる宣言をする契約しないと入れないよ！面倒だから勝手に部屋使うぜ！ 

機密性に関する情報セキュリティ対策の例 ①識別しても、➁認証でユーザーの証明ができないと弾かれる  ①識別 ➁認証しまった！これ宇宙船の鍵だ…  鍵が無い？借主じゃないな！？契約で部屋を借りる宣
言をする 103号室はワームくんが使う鍵を持ってマンションに入る

機密性に関する情報セキュリティ対策の例 ①識別と➁認証を経ても、権限がなければ ③認可で弾かれる  ①識別 ➁認証 ③認可パーくんの部屋にはいっちゃえ！  103号室以外ダメだよ！え、ちょ、怖いよ！ 
契約で部屋を借りる宣言をする 103号室はワームくんが使う鍵を持ってマンションに入る鍵があるから本人だろう借主が借りている部屋に入る

情報へアクセスする「正当さ」    これをコントロールするのが「アクセス制御」です  【機密性】識別・認証・認可とは

アクセス制御    ビジネス要件およびセキュリティ要件に基づいて、  情報資産へのアクセスが許可および制限されることを保証する手段のこと。      ビジネス要件とは、ザックリ言ってしまえば   「事業や業務を遂行するために必要な要件」です。
    どんな事業を行うのか、  その事業ではどんな業務を定義するのか、   その業務ではどんな情報を扱うのか   これらを整理することで、必要なセキュリティ要件を占えます   【機密性】識別・認証・認可とは

機密性に関する情報セキュリティ対策の例 ①～③の各ステップで、様々なアクセス制御方法があります。  ①識別 ➁認証 ③認可ユーザーを登録する開発者が登録されたユーザー本人か確認する ID/PASS
OKだから本人だろう許された範囲でアクセスできる開発環境はOK 本番環境はNG 開発者  システム

機密性に関する情報セキュリティ対策の例 ①識別 ➁認証 ③認可 MFA （Multi-Factor Authentication） ①～③の各ステップで、様々なアクセス制御方法があります。  ユーザーを登録する開発者が登録された
ユーザー本人か確認する ID/PASS OKだから本人だろう許された範囲でアクセスできる開発環境はOK 本番環境はNG 開発者  システム ※ ➁はあくまでも「看做している」だけなので、単純な認証方法（例えばID/PASSの組み合わせのみの単要素認証など）では、成りすましによる不正アクセスを招く可能性が跳ね上がります。   例えば、MFAの導入などにより、ユーザー本人であることの裏付けを採ることが認証では重要になります。  

機密性に関する情報セキュリティ対策の例 ①～③の各ステップで、様々なアクセス制御方法があります。  ①識別 ➁認証 ③認可 RBAC （Role-Based Access Control）ユーザーを登録する
開発者が登録されたユーザー本人か確認する ID/PASS OKだから本人だろう許された範囲でアクセスできる開発環境はOK 本番環境はNG 開発者  MFA （Multi-Factor Authentication）システム ※ ③は、不正アクセスをされた場合、被害の範囲を抑える観点でも重要です。   　例えば、システム内の全てのコンポーネント/データにアクセスできるアカウントが侵害を受けた場合、   　システムの乗っ取りすら可能になってしまいます。  

SSGでは、PERMANという認証基盤も提供しています  ・離退職/異動者の管理  ・SSO  ・MFA  開発者の皆さん PERMAN 【機密性】識別・認証・認可とはクラウドサービスＡクラウドサービスＢクラウドサービスＣ

リスクとは

リスクとは  さて、それでは、    どうすればCIAを満遍なく    維持できるのでしょうか？ 

リスクとは  いきなり具体的な対策から考えると迷走します  いったい何からやればいいんだろう

リスクとは  具体的な情報セキュリティ対策を  考えるためのプロセスを学びましょう 

リスクとは  ここでのキーワードは    「リスク」    です 

リスクとは  情報セキュリティ事故に至る    「リスク」の枠組みを知ることで    「何をすべきか」の糸口を見つけられます 

リスクとはまたまた手堅く    「リスク」の定義から確認しましょう 

特定の「脅威」が「情報資産」の「脆弱性」を悪用し、  それによって組織に害を及ぼす可能性のこと。  これは、イベントの発生確率と  その結果の組み合わせの観点から測定される。  リスク=脅威*脆弱性*情報資産    脅威情報資産脆弱性リスク
【参考】 ISO/IEC 27005:2022 Information technology — Security techniques — Information security risk management リスクとは

リスクとはざっくり言ってしまえば、リスクは  • 情報資産  • 脅威  • 脆弱性  の３要素で  
　測定できるとしているようです 

リスクとは • 「脅威」＝情報資産のCIAを脅かすイベント    • 「脆弱性」＝脅威が悪用する弱点 

リスクとは「脅威」と「脆弱性」について、  定義を確認してみましょう 

脅威  　情報システムを通じた不正なアクセス、破壊、露出、情報の改ざん、  またはサービス停止による、組織の業務や資産、個人、その他の組織または国家に悪影響を与える可能性のあらゆる状況またはイベント    脆弱性  　脅威リソースによって悪用される可能性のある情報システム、  セキュリティ手順、内部統制、または実装における固有の弱点  【参考】 NIST
SP 800-30 Guide for Conducting Risk Assessments リスクとは

リスクとはちょっとややこしいので、  例え話で考えましょう   

リスクとはここからは、下記のワードが頻出します。    • 情報資産  • 脅威  • 脆弱性   
以降、上のように色を分けて表記します。 

例え話）  泥棒によって  鍵が壊れたドアから  壺が盗まれるリスク  について考える   

例え話）  泥棒によって  鍵が壊れたドアから  壺が盗まれるリスク  について考える    脅威  脆弱性  情報資産  「壺」は「情報」資産ではないじゃない…
  というツッコミはしないでね！ 

脅威：泥棒によって盗まれる  脆弱性：鍵が壊れたドア  情報資産：壺  壺GETだぜ！  泥棒は鍵が壊れたドアを悪用して壺を盗む

盗む人が居ない  脅威：泥棒によって盗まれる  脆弱性：鍵が壊れたドア  情報資産：壺  泥棒が存在しなければ、壊れた鍵は悪用されない

盗めない  脅威：泥棒によって盗まれる  脆弱性：鍵が壊れたドア  情報資産：壺  鍵が正常なら、泥棒は悪用できない

盗むものが無い   脅威：泥棒によって盗まれる  脆弱性：鍵が壊れたドア  情報資産：壺 
壺が無ければ、泥棒は盗めない

脅威：泥棒によって盗まれる  脆弱性：鍵が壊れたドア  情報資産：壺  壺GETだぜ！  結論：情報資産・脅威・脆弱性が揃うとリスクを観測できる

リスクとは情報セキュリティ対策を行ううえで  我々は、情報資産・脅威・脆弱性  どれをコントロールできそうでしょうか？   

脅威は基本的にコントロールできない    世界中から泥棒を抹消はできないですね...    自然災害だって人の手でコントロール不可能です  リスクとは

情報資産のコントロールはビジネスに影響する      我々は情報資産を利用してビジネスをしています    情報資産が狙われているからと言って、  その取扱いを直ちに止めるわけにはいきません  リスクとは

情報資産のコントロールはビジネスに影響する      リスクとはただし、保険に加入して損害を補填したり、  壺を警備のしっかりした組織に預けるなど、  他の組織とリスクを共有することは可能です。 

リスクとは脆弱性は、ある程度コントロールできる    壊れた鍵を直すことはできます！ 

リスクとは脅威と情報資産を  認識することで、  具体的な脆弱性が見えてきます！ 

リスクとは具体的な脆弱性が見えてくれば、  対策も具体的に考えられます。 

リスクとは泥棒が壺を狙ってるわ…！    お家確認してみたら、ドアの鍵が壊れているようね。。。    なら、、、    ・監視カメラを設置して犯行を「検知」してみようかしら  ・監視中のステッカーを貼って犯行「予防」していいかも  ・それと、壊れた鍵を直して「是正」しておきましょう！ 

リスクとは安心・安全なサービスのために  脆弱性の潰し込みや、発見・解消に向けて  技術力を使うのがエンジニアの役割です     

リスクとは要するに、サービスが抱える  • 情報資産  • 脅威  • 脆弱性  からリスクを洗い出すことで   
具体的な情報セキュリティ対策を考えられます   

リスクとは実のところ、情報セキュリティの考え方は、  何も特別なものではありません。    皆さんも日常的に意識して実践しています。   

リスクとはカフェでお茶しているけれど、ちょっと席を外したいわ…    だけど、スマホと財布をテーブルに置いたままだと、  他の人がが盗むかもしれないわ…！  こんな感じで、おそらく皆さんも  日常的に無意識レベルで考えて実践しています 

リスクとはリスク分析が甘かったせいで発生した  情報セキュリティ事故事例を見てみましょう   

事例１    概要  　・車両利用者に対しナビゲーション等を提供するサービスにおいて、  　　個人情報を含むデータが、クラウド環境の誤設定により公開状態となっていた    被害（漏れた可能性のある情報）  　・情報：車載端末ID、車台番号、車両の位置情報、時刻  　・件数：約215万人分  　・期間：2013年11月6日
～ 2023年4月17日（10年弱！）  リスクとは

事例１    原因  　・従業員において「何が個人情報に当たるのか」十分な認識が無かった  　・アクセス制御の観点からの監査・点検を実施していなかった    再発防止策  　・個人情報の取り扱いに関する社内教育の徹底  　・クラウド設定を監視するシステムの導入  　・個人情報の取り扱い状況に対する定期的な監査の実施 
リスクとは

この事例の教訓...      リスクとは

リスクとはこの事例の教訓...    そもそもサービスで守るべき「情報資産」を  認識していない  　　　　↓  　リスクを見落としてしまう  　　　　↓  　情報セキュリティ対策が不足してしまう 

リスクとは「『情報資産』って大事だよね！」    と言われれば    おそらく皆さん『YES』と答えるでしょう 

リスクとはですが「『情報資産』って大事だよね☆！」で    思考停止してはいけません。 

リスクとは何が大事な情報資産か見極めないと、    必ず情報セキュリティ対策が甘くなります  社内ポータルサイト等で大事な情報資産に関する  アナウンスなどもしているので、ご参照ください。 

リスクとはここからは、特にエンジニアに  関係するリスクの話をします   

リスクとは「脆弱性」の見落としに起因した  セキュリティ事故の事例を見てみましょう   

事例２    概要  　・エンジニア向けの転職サービスにおいて、  　　本来マスキングされるはずの一部データが、  　　HTMLソース上にて第三者による閲覧が可能な状態になっていた    被害（漏れた可能性のある情報）  　・情報：氏名、企業からのオファー情報等 
　・期間：2022年6月13日～ 2023年6月17日  リスクとは

事例２    原因  　・機能開発におけるシステム設計の考慮漏れ    再発防止策  　・システム設計時の社内レビュー体制を拡充する  　・社外・第三者によるレビュー体制を導入する（検討する）     
サイバーエージェントでは、リリース前、および、  リリース後も定期的に脆弱性診断を実施しています。  脆弱性診断後の改修も踏まえて、  開発スケジュールを立てましょう。  リスクとは

事例3    概要  　ソフトウェアフレームワーク「Apache Struts 2」の脆弱性を  　悪用した不正アクセスの事例      この脆弱性の悪用は、 
多くの企業に被害を及ぼしました。    ここでは、脆弱性がどのようなスピード感で  悪用されるのか一例を紹介します。  リスクとは

事例3    概要  　ソフトウェアフレームワーク「Apache Struts 2」の脆弱性を  　悪用した不正アクセスの事例    被害  　例えばある企業においては、下記のような被害が発生した。 
　・クレジットカード番号・有効期限・セキュリティコード  　・メールアドレス等の個人情報の漏えい    ※ この企業では、再発防止委員会の設置、コールセンター設置、  　フォレンジック対応、経済産業省への報告対応、  　 PCI DSS再審査対応など膨大な事後対応も発生した  リスクとは

事例3    原因  　Apache Struts 2の脆弱性（S2-045/CVE-2017-5638）対応が遅れたため  「遅れた」とありますが、、、    当時、US Apache
Siteで脆弱性情報が公開された翌日には、  Githubで攻撃コードが公開されています。    そして、攻撃コード公開の翌日には、攻撃が開始されています。    このように、脆弱性が公開されてから攻撃に転用されるまでの  スピードは、皆さんの想像を超えるレベルで早いものです。  リスクとは

サイバーエージェントでは、SSGからもツールやソフトウェアなどの脆弱性に関する情報を配信しています。  脆弱性に関する情報を収集する手段は様々あります。    しかし、自分たちがどのようなツールや  ソフトウェアを利用しているのか把握していなければ、  必要な情報を収集できません  リスクとは

リスクとは  よく知られている「脅威」に対抗するため、  「脆弱性」を作り込まない、見過ごさないのが、  エンジニアの重要なミッションです。      　　　　　　　　　　とは言え、、、 

リスクとは  エンジニアとしては、  「具体的にどこまで何をすれば良いのか」  イメージが湧かないかもしれません    このヒントになるのが、法律やガイドラインです    詳しくは後ほど一緒に学びましょう 

おさらい：「リスク」は  情報資産・脅威・脆弱性により特定できる。  • 守るべき情報資産がある  • CIAを損なう脅威がある  • 脅威に対する脆弱性がある  リスクとは

このようにリスクを識別する行為を    「リスク特定」と言います  リスクとは

リスクアセスメント

おさらい  • リスク=脅威*脆弱性*情報資産  　　　  しかし、、、  リスクアセスメント脅威情報資産脆弱性リスク
【参考】 ISO/IEC 27005:2022 Information technology — Security techniques — Information security risk management

「リスク特定」だけでは、  情報セキュリティ対策を進めるのに  まだ十分ではありません。    なぜなら、、、  リスクアセスメント

その「リスク」が  どの程度「ヤバい」のか決めないと  優先順位を決められないからです。  リスクアセスメント

優先順位を決めないと  他人に説明できる根拠（指標）が  示せず時間やお金を使えません、、、  リスクアセスメント

なので、特定した「リスク」の  ヤバさの程度を表現してあげる必要があります  →　これが「リスク分析」です  リスクアセスメント

脅威情報資産脆弱性リスク • 情報資産  • 脅威  • 脆弱性 
これらを何らかの手段で数値化して、  リスク値を測定する方法があります    　☛ それぞれの円が大きくなると  　それだけ「リスク」も大きくなる  リスクアセスメント

例）  ◦ 情報資産を損なう影響  ▪ （１:影響なし～４:経営に大きな影響）  ◦ 脅威の発生頻度  ▪ （１:数年に1回～４:月に1回以上）  ◦
対策の脆弱性  ▪ （１:強固に対策済み～４:何もしていない）  リスクアセスメント

当てはめ）  　医療情報を扱うシステム  　　＝経営に大きな影響「４」  　犯罪者による不正アクセスの可能性  　　＝年に1回以上「３」  　パスワード認証のみ実装している  　　＝少し対策済み「３」 
　　　　　　⇒ ４×３×３＝リスク値「３６」  リスクアセスメント

【参考】リスク評価のメソッド例  • DREAD  ◦ 5要素を評価し平均値スコアとする  ▪ Damage Potential（損害の可能性）  ▪ Reproducibility（再現性） 
▪ Exploitability（悪用のしやすさ）  ▪ Affected Users（影響を受けるユーザ）  ▪ Discoverability（発見のしやすさ）  リスクアセスメント【原文】 Microsoft Build　Chapter 3 – Threat Modeling

【参考】リスク評価のメソッド例  • CVSS（Common Vulnerability Scoring System）  ◦ 脆弱性を定量的に評価するためのフレームワーク  ▪ 影響範囲、攻撃の複雑さ、影響等を基にスコアを算出する 
リスクアセスメント

【参考】リスク評価のメソッド例  • CVSS（Common Vulnerability Scoring System）  ◦ 脆弱性を定量的に評価するためのフレームワーク  ▪ 影響範囲、攻撃の複雑さ、影響等を基にスコアを算出する 
リスクアセスメント先ほど紹介した事例3の  「Apache Struts 2」のCVSSスコアは  v2で最高値の10.0（危険）とされていました 

リスクアセスメントさて、リスク値で優先順位を定めたら、  今度はどのようにアプローチするべきでしょうか？ 

リスクアセスメントいきなり具体的な対策を考える前に、  大枠として「4つのアプローチ」を抑えましょう。 

リスクアセスメントリスクに対する「4つのアプローチ」 

リスクアセスメント • リスク低減  ◦   • リスク回避  ◦   •
リスク移転  ◦   • リスク保有  ◦   【参考】ISO 31000:2018 — Risk management

リスクアセスメント • リスク低減  ◦ 具体的に脆弱性を潰し込むことでリスク値を下げる考え方です  • リスク回避  ◦ 情報資産の取り扱いをやめる考え方です  •
リスク移転  ◦ リスク発生を別の組織体と共有する考え方です  • リスク保有  ◦ リスクがあると自覚して受け入れる考え方です  【参考】ISO 31000:2018 — Risk management

リスクアセスメントエンジニアの皆さんに関わる  「リスク回避」の例をご紹介します 

リスクアセスメントアプリケーション  ランタイム  ミドルウェア  コンテナ管理機能  OS  仮想マシン  ハードウェア  アプリケーション  ランタイム 
ミドルウェア  コンテナ管理機能  OS  仮想マシン  ハードウェア  アプリケーション  ランタイム  ミドルウェア  コンテナ管理機能  OS  仮想マシン  ハードウェア  アプリケーション  ランタイム  ミドルウェア  コンテナ管理機能  OS  仮想マシン  ハードウェア  オンプレミス  IaaS  PaaS  SaaS  データ  アカウント  データ  アカウント  データ  アカウント  データ  アカウント  クラウドサービスプロバイダの責任   クラウドサービスカスタマの責任   ▪ クラウド責任共有の例   皆さんがクラウドサービスを利用する場合「クラウドサービスカスタマ」となります。     皆さんがクラウドサービスを提供する場合「クラウドサービスプロバイダ」となります。     例えば、AWSやGCPなどを利用して開発をする場合、クラウドサービスプロバイダ側にセキュリティに関する対応を委ねることとなります。     その結果、皆さんは自分の責任を負う範囲に注力することが可能となります。  

クラウドプロバイダのサービスを  利用する場合、どのレイヤーが  プロバイダの責任なのか確認が必要です。    また、クラウドサービスプロバイダの  セキュリティ体制を確認することも大切です。    参考：AWS 責任共有モデル  リスクアセスメント

リスクアセスメント • リスク低減  ◦ 具体的に脆弱性を潰し込むことでリスク値を下げる考え方です  • リスク回避  ◦ 情報資産の取り扱いをやめる考え方です  •
リスク移転  ◦ リスク発生を別の組織体と共有する考え方です  • リスク保有  ◦ リスクがあると自覚して受け入れる考え方です  特定・分析したリスクをどのアプローチで  処理するか定めることを「リスク評価」と称します。 

リスクアセスメントリスクの特定・分析・評価、この一連の取り組みを  「リスクアセスメント」と言います。  SSGではリスクアセスメントをサポートしています。  ① リスク特定 ➁ リスク分析 ③ リスク評価
④ 優先度順に対応を推進する

リスクアセスメント SSGでは、クラウド等のリスクを  可視化するサービスも提供しています  管理者 RISKEN 人力でリスク把握は大変自動的にリスク評価を実施評価結果を共有
クラウド上に構築したシステム

リスクアセスメント 4つのリスク対応を踏まえた、リスク対応のおさらい  1. 「リスク特定」「リスク分析」により現状を把握する  a. 情報資産は何で、それはどの程度重要か？  b. 脅威（CIAを脅かすもの）はどのくらいの頻度で起こり得るか？  c. その脅威に対して今何をしており、それはどの程度脆弱か？ 
  2. 「リスク評価」でアプローチの方針を定める  a. 「リスク低減」「リスク回避」「リスク移転」を検討する  b. 優先度がものは「リスク保有」でリスクを自覚する    3. 「リスク評価」で定めたアプローチの具体案を検討する   

リスクアセスメント全てのリスクを「ゼロ」にすることは極めて困難です。    しかし、リスクアセスメントによりリスクを可視化し、    優先順位を付けていけば、順繰りに対策が取れます。 

法律・ガイドライン

法律・ガイドラインエンジニアが  なぜ「法律・ガイドライン」を  知らねばならないのか？ 

法律・ガイドライン「法律は守らないとダメ」  もちろんそれは正論ですが、  エンジニアにとって情報セキュリティの観点で、  知るメリットが存在します。 

法律・ガイドラインそれは、法律やガイドラインが  「情報セキュリティ対策の最低ラインになる」です 

法律・ガイドラインそもそも法律やガイドラインは、国や業界団体が  リスクアセスメントして作っているものです。 

法律・ガイドラインもし法律やガイドラインが存在しなかったら、、、  我々はゼロベースでリスクアセスメントして、  情報セキュリティ対策を考えねばなりません。 

法律・ガイドラインゼロベースでリスクアセスメントをすると、、、  • 業務と併せてリスクアセスメントするのは大変  • 情報資産、脅威を見落として脆弱性が残るかも 

法律・ガイドライン独立行政法人情報処理推進機構（IPA）から  出されているガイドラインの例    • Web Appliサイバーエージェントtion Firewall 読本  https://www.ipa.go.jp/archive/security/vuln/waf.html 
• 安全なウェブサイトの作り方  https://www.ipa.go.jp/security/vuln/websecurity/about.html   • ECサイト構築・運用セキュリティガイドライン  https://www.ipa.go.jp/security/guide/vuln/guideforecsite.html  ◦ IPAセキュアプログラミング講座  https://www.ipa.go.jp/archive/security/vuln/programming/index.html 

法律・ガイドライン PCI DSS  ◦ ロールベースでのアクセス権付与  ◦ アカウントの厳格な管理  ◦ 定期的な脆弱性診断/侵入テストの実施　など 

法律・ガイドライン PCI DSS  ◦ ロールベースでのアクセス権付与  ◦ アカウントの厳格な管理  ◦ 定期的な脆弱性診断/侵入テストの実施　など  PCI
DSSは、クレジットカード会員データを  安全に取り扱う事を目的として策定された、  クレジットカード業界のセキュリティ基準です  その要件数は400を超えます。 

法律・ガイドライン ISMS  ◦ リスクアセスメントの実施  ◦ リスクアセスメントに基づく情報セキュリティ計画の策定  ◦ 内部監査の実施　など 

法律・ガイドライン ISMS  ◦ リスクアセスメントの実施  ◦ リスクアセスメントに基づく情報セキュリティ計画の策定  ◦ 内部監査の実施　など  ISMSの認証には、必ず第三者機関の審査が必要です。   
サイバーエージェントグループでは、例えばMG-DX社がISMSの認証を受けており、ISMSのセキュリティ管理策を遵守しています。 

法律・ガイドラインとは言うものの 

法律・ガイドライン具体的にどの法律やガイドラインを  見るべきでしょうか？ 

法律・ガイドライン実際は、事業で取り扱っている情報資産や、  業界の特性から法律やガイドラインを  ピックアップすることになります 

法律・ガイドライン例えば、  • 個人情報を扱っている　＝　個人情報保護法　等  • 入札で公的な認証が必要　＝　ISMS、Pマーク　等  • クレジットカード情報　＝　PCI DSS  　…などなど、情報資産やビジネスを見て、 
　　必要なものをピックアップすることになります。 

法律・ガイドラインエンジニアに関わる部分で、もう少し  法律やガイドラインについて掘り下げましょう   

法律・ガイドライン自分の担当するシステムについて  「情報セキュリティ対策もキチンとすべきだ」  と言われるかもしれません。 

法律・ガイドラインこれは、一見するとド正論です。  しかし、、、 

15 2 何をもって「キチンと」取り組んだ  と言えるのでしょうか？ 

法律・ガイドラインこの「キチンと」の基準になり得るのが、  法律やガイドラインです 

法律・ガイドラインちょっと事例を見てみましょう 

法律・ガイドライン事例４  ECサイトに内在する脆弱性を悪用されて情報漏洩に至った事例    X  【発注者】  Y  【受注者】  敗訴  【参考】東京地判平26.1.23判時2221-71

法律・ガイドライン事例４      敗訴  ECサイト開発してください！わかりました！ X  【発注者】  Y 
【受注者】  【参考】東京地判平26.1.23判時2221-71

法律・ガイドライン事例４  X社の  ECサイト  敗訴  さぁビジネスするぞ！できました！ X  【発注者】  Y 
【受注者】  【参考】東京地判平26.1.23判時2221-71 DB

法律・ガイドライン事例４  X社の  ECサイト  敗訴  個人情報やクレジットカード情報を保存 X  【発注者】  Y 

法律・ガイドライン事例４  X社の  ECサイト  SQLインジェクションの脆弱性を  悪用してDB内の情報を窃取  へへへへ… お宝の山だぜぇ！！ X  【発注者】 
Y  【受注者】  【参考】東京地判平26.1.23判時2221-71 DB

法律・ガイドライン事例４  X社の  ECサイト  敗訴  欠陥品作りやがって！損害賠償だ！１億払え！ X  【発注者】  Y 

法律・ガイドライン事例４  X社の  ECサイト  敗訴  欠陥品作りやがって！損害賠償だ！１億払え！ X  【発注者】  Y 
【受注者】  セキュリティの仕様を指示してないじゃん！【参考】東京地判平26.1.23判時2221-71 DB

法律・ガイドライン事例４  敗訴  裁判官  Yはプロなんでしょ？  だったら、やるべきことをやる義務があるよね。    IPAとか経産省のガイドラインでも  「SQLインジェクションの対策は必須」って  書いているじゃん。 
  ま～さすがに１億円の責任は無いけど、  Yはやるべきことやったって言えないから、  2千万円を損害賠償としてXに支払ってね。  【参考】東京地判平26.1.23判時2221-71

法律・ガイドライン我々はプロとして仕事をする立場なので、  法律やガイドラインを意識しないと、  「キチンとやった」と評価されないかもしれません。 

プライバシー保護

プライバシー保護そもそも「プライバシー」とはなんでしょう？   

プライバシー保護いつものように  まずは定義から確認しましょう。   

プライバシー保護 “他人の干渉を許さない、各個人の私生活上の自由”  　自分が他人に知られたくない情報のこと  【引用】総務省　プライバシー情報の取り扱い

プライバシー保護たとえば…  1. 個人情報  2. 医療情報  3. フィナンシャル情報  4. インターネット使用情報 
5. 通信情報  6. 生物学的特徴 

プライバシー保護法律でも、プライバシー保護を図るものがあります  1. 刑法  2. 民法  3. 個人情報保護法  4. プロバイダ責任制限法　等 

プライバシー保護プライバシーが大事かどうかの価値観は人によるかもしれません    しかし！    少なくとも「プライバシー」は法律で  保護されるに値するものである（取り扱い注意な情報資産）と評価されている  ことは意識しましょう。 

プライバシー侵害の当事者になった場合に想定される影響の例  • 賠償金支払い  ◦ 個人情報保護委員会からの命令違反の場合の参考  ▪ 法人：1億円以下の刑事罰  （個人：1年以下の懲役または100万以下の刑事罰）  ▪ 社会的信用の失墜 
▪ システム変更に伴う改修コスト  ▪ その他  プライバシー保護

プライバシーのうち、  サイバーエージェントで最も取り扱いが多いのが  「個人情報」です。  プライバシー保護

サイバーエージェントでは、  個人情報の取り扱いについて  ホームページでもポリシーを宣言しています。    サイバーエージェントプライバシーポリシー  https://www.cyberagent.co.jp/privacy/  プライバシー保護

個人情報の難しいところは、  「これって個人情報になるの？ならないの？」  の判断が即答できないケースがあることです。  プライバシー保護

プライバシー保護今日の「事例１」を思い出してください。   同事例では「車載端末ID、車台番号、車両の位置情報、時刻」について、   システム運用者はこれらが個人情報との認識がありませんでした。   個人情報の難しいところは、  「これって個人情報になるの？ならないの？」  の判断が即答できないケースがあることです。 

まずは「個人情報」の定義から押さえましょう。  プライバシー保護

個人情報  「個人情報」とは、生存する個人に関する情報であって、当該情報に含まれる氏名、生年月日、その他の記述等により特定の個人を識別することができるもの（他の情報と容易に照合することができ、それにより特定の個人を識別することができることとなるものを含む。）、又は個人識別符号が含まれるもの  　　　　　　　　　　　【参照】個人情報の保護に関する法律 2条1項  プライバシー保護大まかに言うと、情報の取扱い状況から  「個人を特定できる」か否かがポイントになります。 

「個人を特定できるか」という観点で、  もう少しいろいろな情報を見ていきましょう。  プライバシー保護

下記のどれが個人情報に該当するでしょうか？  1. 遺伝子情報  2. 指紋データ  3. マイナンバー  プライバシー保護

プライバシー保護答えは「全て個人情報に該当する」です。    遺伝子情報も、指紋データも、マイナンバーも個々の人間が持つ固有の情報なので、個人を特定することが可能です。    よって、個人情報に該当するものです。 

では、下記は個人情報に該当するでしょうか？  1. メールアドレス  2. 人名のイニシャル「H・T」  3. 統計データ内にある目黒区在住の41歳男性  プライバシー保護

プライバシー保護答えは「全て個人情報に該当する可能性がある」です。    まず、メールアドレスもイニシャルも他の情報と合わせたり、復元することで個人を特定できる可能性がある場合、個人情報に該当することがあります。    特にメールアドレスはユーザー名＠ドメインの組み合わせで、個人の特定ができる場合、単独でも個
人情報になる可能性があります。 

プライバシー保護統計データは、他の情報と合わせたり、復元しても個人を特定できない場合、個人情報に該当しません。    このような情報を「匿名加工情報」と呼びます。    逆に言えば、復元により個人を特定できる状況であれば、それは個人情報になります。 

最後に下記は個人情報に該当するでしょうか？  • Cookie ID  プライバシー保護

プライバシー保護答えは「個人情報に該当する可能性がある」です。    Cookie IDは、ウェブサイトがユーザー再訪時に当該ユーザーを認識するもので、これ単独では個人を特定できるものではありません。    しかし、特定の情報と組み合わせて個人を特定できる場合は、その特定の情報と合わせて個人情報
となります。 

プライバシー保護なお、日本の個人情報保護法では、Cookie単体で個人情報とはみなしません（個人に関連する「個人関連情報」としてルールを定めています）。    しかし、GDPRではCookie単体でも個人情報とするなど、国により扱いが違う点に注意が必要です。 

Cookie IDの取扱いについては、  サイバーエージェントもポリシーを出しています。    サイバーエージェントクッキーポリシー  https://www.cyberagent.co.jp/cookie/  プライバシー保護

インシデント対応概論

さて、ここまでは、  情報セキュリティ事故を如何に発生させないかに  フォーカスを当てて話してきました。  インシデント対応概論

しかし  インシデント対応概論

19 1 情報セキュリティ事故は、  大なり小なり必ず発生します 

なぜなら、リスクはゼロにできないからです  インシデント対応概論

• 情報セキュリティ事故の予兆をいち早く察知する  • 情報セキュリティ事故が発生したら即座に対応する    この仕組み作りがポイントになります。  インシデント対応概論

まずは、何が「情報セキュリティ事故」に  当たるのかを理解しましょう。  インシデント対応概論

インシデント対応概論 ▪ 情報セキュリティ事故（ISO/IEC 27000）  　一つ以上の情報セキュリティインシデントが  　組織の情報セキュリティを著しく影響させる  　可能性がある状態     

    続けて、  「情報セキュリティインシデント」の  定義も確認しましょう  インシデント対応概論

▪ 情報セキュリティインシデント  （ISO/IEC 27035）  　情報セキュリティの  • ポリシー違反または失敗  • またはその防護措置の違反または失敗  インシデント対応
概論

情報セキュリティ事故に至らせない、  または、至っても被害を拡大させないためには、  「情報セキュリティインシデント対応を早急かつ適切に行う」  ことが大切です  インシデント対応概論

エンジニアの皆さんは、  システム設計・構築・運用に携わるため、  情報セキュリティインシデントに  関わる機会が多くなります。  インシデント対応概論

まずは、配属先組織におけるインシデント対応のフローを確認し、  何かあったら、早急にフローを遂行できるようにしましょう。      インシデント対応概論

20 1 皆さんの早急な対応が、    サイバーエージェントの事業継続を左右することになります

エンジニアの皆さんにお願いしたいこと。  • インシデントかも...と思ったら、  即座にインシデント対応フローに基づき報告・連絡・相談してください！  • 少しでも早い対応が、被害拡大の阻止につながります  インシデント対応概論

まとめ

まとめ ▪ 情報セキュリティとは？  　機密性、完全性、可用性を維持すること  ▪ そのために何をするの？  　情報資産、脅威、脆弱性からリスクを把握する  ▪ インシデント 
　100％は防げない！必ず配属先の対応フローを押さえよう  　 

おわり

セキュリティ研修 〜マネジメントパート〜（サイバーエージェント新卒研修2024）

セキュリティ研修 〜マネジメントパート〜（サイバーエージェント新卒研修2024）

More Decks by CyberAgent

Other Decks in Technology

Featured

Transcript

セキュリティ研修〜マネジメントパート〜（サイバーエージェント新卒研修2024）

セキュリティ研修〜マネジメントパート〜（サイバーエージェント新卒研修2024）