こんにちは！TECH Street編集部です！
今回は2022年8月18日（木）に開催した、 「セキュリティエンジニア勉強会〜社内のセキュリティ環境ってどうしている！？知見・課題を共有〜」のイベントレポートをお届けします。
はたらき方の変化に伴い、ここ数年で社内の業務フローや業務環境なども変化してきていると思います。セキュリティ運用担当者はその変化に合わせて常に安全な環境を用意しなければなりません。
イベントではベンダー側と事業会社側それぞれの視点で、各社のセキュリティ運用担当者が環境変化に伴い、どのような課題と向き合い、どのように対応してきたのかなど課題や知見を共有する会を開催しました！
登壇者は
臼田 佳祐さん／クラスメソッド株式会社
柿田 一さん／パーソルキャリア株式会社
月島 学さん／パーソルキャリア株式会社
早速、内容を紹介いたします！
まずはクラスメソッド株式会社 臼田さんの発表です。
AWS環境のセキュリティ、どうやってチェックしてる？
※登壇資料はコチラ
クラスメソッド株式会社AWS事業本部のセキュリティチームでリーダーを務めている臼田と申します。今回はAWSのセキュリティ対策にまだ本格的に取り組めていない情シスやセキュリティエンジニアの皆さんに向けて、3つのことを持ち帰っていただきたいと思います。
＜持ち帰っていただきたいこと＞
・とにかく「最強のAWS基礎セキュリティベストプラクティスを使う」ということ。
・全員巻き込んでポジティブにセキュリティを強化すること。
・中級以降からAWSの知識は必須。
AWSのセキュリティはどこからやるの？
まずはAWSセキュリティをどこからやるのか？についてですが私はクラウド特有のセットアップが重要だと考えます。
最初にやっていただきたいのはIAMユーザーの作成です。AWSアカウントを最初に作るときにできるルートユーザーは使ってはいけないというベストプラクティスがあるため、MFAで使わないように封印しておきましょう。
IAMについて
“IAM”は聞きなれない方々もいらっしゃるかもしれませんが【Identity and Access Management】の略でありAWSにおけるアクセス制御の基本かつ極意です。IAMを知っている人でも突き詰めていくと知らないこともあるので、常に抑える必要があるサービスです。
次に必要なサービスを有効化していきましょう。主要なサービスをピックアップして解説します。
CloudTrailについて
AWSはほぼすべての操作がAPIで実行されますが、そのAPIの実行履歴を記録するサービス＝CloudTrailを有効化してログの保存が重要になってきます。
Configについて
AWSの各リソース単位の設定変更を管理できるAWS Configで、変更履歴を管理できるように設定しましょう。
Well-Architectedフレームワークについて
AWSのベストプラクティスを把握してAWSを使うということで、Well-Architected フレームワークを使います。実際にシステムを作る、運用していく上ではこの5つの柱が重要な要素となるので、これらをしっかりと押さえていく必要があります。
Well-Architected フレームワークはスルメのようなもの。
これは膨大な資料で、詳細に書かれた別の資料もあるので、読み込むためにはとても時間がかかります。よって最初は概要レベルでさらっと読み、繰り返し読んでいくことによってだんだんと理解ができるようになっていくとおもいます。
AWSに関わるどのフェーズでも参照できるドキュメントになっているので、スルメのように何度も咀嚼して使うのがオススメです！しかし最初からこのドキュメントを見てもよく分からないのでこういったブログなどの解説を見ながら活用すると良いと思います。
AWS Security Hubを使ったセキュリティチェック
AWSを利用する大前提としてすべてのAWS利用者は、AWSの基本的なセキュリティを理解する必要があります。例えば、社内でAWSのサービスを使う場合には最低限押さえるべき社内のルールを作り、ベースラインを作るためのベーシックな教育プランのコンテンツやドキュメントを用意するといったことが大切になります。
とはいえ、ゼロベースで考えるのは大変…よってAWS Security Hubを使ったセキュリティチェックを活用するとよいと思います。そもそもAWSの良いところはマネージドサービスで“楽“ができるところです。
マネージドサービスとは？
AWSにはある程度の仕組みが用意されているので、やりたいことを実現するためのインフラストラクチャーを利用することができます。
インフラストラクチャーの管理も重要な仕事の1つですが、管理だけを行えばよいというわけではありません。そのインフラストラクチャーを使ってビジネス上の成功をおさめる、ビジネスに貢献することが大事だと思いますので、やらなくても良いことはAWSに任せるなどして他の業務に集中してもらいたいと思います。
セキュリティに関するマネージドサービスはいくつかありますが、その中でも先ほど「AWS Security Hub」についてご紹介します。
対応リソースが38種類もあり、カバレッジが非常に広いのがAWS Security Hubの特徴です。
運用する上でのポイントは…
「AWS Security Hub」を使うと、一括で設定が可能です。あとはあがってきた項目に対応するだけで、セキュリティが向上していくのでとても効率的です。
しかし、「AWS Security Hub」を有効化して終わりではありません。継続的に新しいリソースを作成し、新しい設定をいれると、それが正しい設定なのか、より良い設定が他にないかを「AWS Security Hub」が都度チェックしてくれるようになります。そしてチェック時に新しい問題が起きたことを通知する設定をしておくことも重要です。デフォルトでは通知を飛ばすという機能はついていないので、ご注意ください。
さらに共有＆見える化のためにみんなが見える場所に通知して展開することも必須です。担当者だけに通知しても意味がありません。
次に「AWS Security Hub」の直接的な機能ではないのですが、違反項目を自動的に修復するソリューションもあります。ぜひこちらも使っていただくと良いと思います。しかしよく検証してから活用することをおすすめします。
クラウドセキュリティのメリットを最大限享受するには
AWSのセキュリティの考え方として「AWSに関わる人すべてがセキュリティの担当者であり全員でセキュリティの課題に取り組むこと」が重要で役割や対応する範囲などが違うだけで、多かれ少なかれAWSに携わるということは、みんなで協力してセキュリティを担当するべきです。
AWSのセキュリティスコアはみんながチェックできるようにしていきましょう。
周りを巻き込む手法として、セキュリティスコアを関係者に全体通知すると良いでしょう。ただ、残念なことに現在はセキュリティスコアをAPIで直接取得することはできません。取得する方法はこちらで紹介していますので是非参考にしてみてください。
またセキュリティスコアを全体通知する際に重要なのは「セキュリティスコアの高い順に通知して称えあう」ことです。セキュリティスコアが低い順のランキングは経験上何も生み出しません。ネガティブなフローが回ってしまいますので避けたほうが良いでしょう。ポジティブにセキュリティ対策することがとても大事です。
クラウド利用範囲が広範囲になってきたらCCoEなど、クラウドを推進する組織づくりに力を入れる必要もでてくると思います。
様々な部門を早い段階から巻き込むことがポイントとなるでしょう。
まとめ
・基本的なセットアップをやる
・Security Hubを有効化してAWS基礎セキュリティのベストプラクティスを活用する
・全員で取り組める仕組みを作り、周りを巻き込む
この3つがAWSセキュリティに取り組む上で必要になってくると私は考えています。
Q＆A（クラスメソッド 臼田さん）
（Q）クラスメソッドさんは様々な企業のAWS導入支援をされていらっしゃいますが、セキュリティ設定の失敗・課題アリパターンなどはこれまでどのようなものがあったのでしょうか。
→細かい例はお話できませんが、運用されないセキュリティが一番課題だと感じています。色んな要素、課題がありますが、入れたはいいけど実際は使っていないということもあります。例えばAWS Security Hub入れたはいいけど、そこから修正など出来ていない。有効化したあとに自動的に上がってくる修正ポイントを是正ができてない点がもったいないと感じています。
（Q）AWSは未体験なのですが、AzureやGCPなどとも共通する、重要ポイントも知りたいです。
AzureやGCPは特に注力していないのでわかりませんが、それぞれ、クラウドに注力しているサービスですね。AWS含め、クラウドは楽しいものだと思っています。従来のITシステムは泥臭い感じのものが多かったです。１つのことをやるのにインフラをしっかり組んだり、工程が多かった。クラウドはオンプレミスに比べると圧倒的に簡単にできるのが良いところです。クラウドだから、良くなっている部分は他のサービスも同様に良いところだと思います。そこに注目して使ってみてください。
（Q）クラスメソッドさんといえばAWSですね。エンジニアとしてのAWS情報はどこで収集していますか？
社内にAWSに詳しいエンジニアが沢山いるので、質問・相談がしやすく環境には恵まれています。自分では、AWSがリリースしている最新情報のRSS( https://aws.amazon.com/jp/new/ )などを眺めています。これは、毎朝必ずチェックしています。その中で自分が注力している分野は、実際に触ってチェックしたりブログに書いたりキャッチアップをしています。ただRSSから直接情報を収集するのも大変なので、まとまったわかりやすい情報として週刊AWSも参考になります
（Q）クラスメソッドさんの体制、エンジニアのなかのセキュリティ担当？の位置付け？知りたいです
うちの会社でも「情報システム部」のような部門があります。会社としてもAWSを活用していますので、私の部署とは別なのですが、社内セキュリティの部門と相談しながらお手伝いすることもあります。
（Q）セキュリティ観点で他に無いAWSの良さ、また、ここもうちょい改善求む、をお聞きしたいです。
（他サービスとの比較はできませんが）個人的に感じる良さは、AWS Security Hubみたいに人が泥臭いことをやらなくても、AWSがうまくやってくれる点です。
他にもAmazon Detectiveではログを分析して自動的に関連性を紐づけしてくれるところが楽になるので助かってます。改善点というかコンセプトの違いですが、AWSのサービスはビルディングブロックとして色んな機能をパーツごとにリリースしているので、自由度が高い反面、組み合わせて使うにはナレッジやコツが必要なところは意識する必要があります。
続いてパーソルキャリア 柿田さんの発表です。
事業会社のITセキュリティ担当のゼロトラスト導入に向けた挑戦
突然ですがみなさん、自社のセキュリティ対策のレベルはどのように評価していますか？
それぞれ課題感や問題意識を持っているからこそ、今回のイベントに参加しているのではと思います。
例えばこのようなサイバーセキュリティ事故を経験された方もいらっしゃるのではないでしょうか？
ITセキュリティの世界においてターゲットにならない企業は存在しません。いかに攻撃者に厄介な相手と思わせるか、攻撃しにくい相手と思わせるかが大切です。
守りの部分で採用している製品や構成の開示は避けたいという企業も多いかと思いますが、今回の発表内容を参考に「まずは試してみよう」と思っていただける方が少しでも増えれば幸いです。
本日はエンジニアリング環境におけるゼロトラスト導入の挑戦についてお話したいと思います。
※前提として「エンジニアリング環境」とは個人情報が蓄積されている環境とは異なる開発用の環境を指します。
ゼロトラスト導入に挑戦した経緯
パーソルキャリアは10年ほど前にエンジニア組織を立ち上げ、テクノロジー本部が立ち上がったのはここ数年です。今でこそ数百名規模のエンジニア組織となりましたが、それまでは外注中心で、内製開発が進んできたのもここ数年の出来事です。その変遷から「エンジニアリング専用の環境が社内にない」ことが課題となっていました。
こちらの図は以前までの社内と外部の構造です。
クラウドファーストと言われる状況ながら、そもそもクラウドにつなぐためにはプロキシサーバを経由する必要があります。しかし、その申請から承認までに驚くほど時間と手間がかかっていました。その結果、生産性もモチベーションも落ちるという由々しき事態に陥っていました。
そこで…そのような状態を解消するためにゼロトラスト導入の挑戦が始まりました。
何のためにゼロトラストを導入するのか
ゼロトラストを導入すること自体が目的とならないように、「何を実現するために
ゼロトラストを導入するのか」をまずはしっかりと定義しました。
やはり開発を進める上でネックとなっていた
１．外部クラウドサービス利用申請の障壁撤廃
２．１による開発効率/柔軟性の低下防止
に重点をおいてCASB（Cloud Access Security Broker）から試そうと判断しました。
CASB導入後の構成
まずCASB導入後の社内と外部の構造はこちらです。
あくまで端末にCASBのエージェントを入れて、そのエージェント経由でもろもろのクラウドサービスを使用するようにしました。内部ネットワークは根本的に変えるのは難しいので引き続き残っていますが、新しく作ったエンジニアリング環境と外部との間には、ゼロトラストによる防御ベースを導入しました。
では「CASB導入に際して難しいプロセスがあったか」というと、以下の2ステップのみです。
・CASB（DLP含む）での制御ポリシーの設定
・対象者端末へのエージェント配布
これ以降は試行利用を続けてもらいフィードバックを受けてチューニングを繰り返しました。
ただ「その制御ポリシーを決めるのが苦労する」という方も多いと思いますので、パーソルキャリアが実装しているポリシーの一部をご紹介します。
弊社では細かく制御はしていません。最低限守りたいというコンセプトを決めたら、それを実現するためのポリシーを設定するようにしています。我々は転職支援のサービスを提供しているので、お客様の個人情報をお預かりしています。この情報は絶対に死守、最も高いプライオリティで守らなければならないので、個人の情報に関しては外部取り扱いをNGとしています。例えば設計書の情報など、これに属さない機微な情報であれば扱って良いという前提になっていますが、それを個人で使っているメールなどに載せてしまうのはもちろんNGです。
CASB以外にもSASEの機能をいくつか採用しています。
みなさんがゼロトラストに挑戦する際に、最初に導入するのは＜IDとアクセス制限を管理＞できる【IAM】になるかと思います。
認証認可を最初に整備した上で、制御のところを整えるというのが自然な流れになるでしょう。
こちらはCASB導入後の全体図です。
青みがかっているオブジェクトが採用済み、グレーのオブジェクトは未採用となっています。
ゼロトラスト導入時に技術周りで苦戦したこと
参考までにゼロトラスト導入時に技術周りで特に苦戦したことをご紹介します。
ご存知の方もいらっしゃると思いますが、CASBはNetskopeさんの製品を使用しています。
簡単に仕組みを説明するとネットワークのエージェントがデバイス側に入ってきて、そのエージェントがNetskopeのプロキシサーバーを経由して、クラウドアクセスをするという仕組みになっています。
実はこのネットワークのプロキシを経由する段階でNetskopeが元の証明書を複合化して、「自己証明書」を添付します。そのため、サーバ側で個別に証明書を持っている場合は、「Netskopeが発行して添付する証明書もちゃんと信頼してね」という設定を対象にする必要があります。サービス毎に一回設定をすれば終わりではなく、デバイス毎に設定をする必要があるため「正直面倒くさいんですけれども・・」というお話を結構いただきました。
ただ、大変ではありますが、手順書やスクリプトも用意しながら環境を整えることによって、利用者の協力と理解を得ることができました。
私が大事なポイントとして考えているのはエンジニアのプライバシー面、心理的安全性の配慮です。
その上で
・アクセスログは蓄積していること
・不正な情報持出や明らかに業務上無関係なサイトの閲覧時はアラートが生成され、操作内容について確認する可能性があること
この2点に関して事前同意を得ることでゼロトラストの導入が浸透することができました。
まとめ
最後に改めてゼロトラスト導入のポイントをまとめますと
・SASEはツールや機能の導入が目的ではない
・自社のニーズや目的に照らして、段階的に導入することが重要
・導入できるからスモールスタートで「まずやってみよう」というマインドが大事
この3つに重点を置いて皆さんの企業でも導入を検討してみてはいかがでしょうか。
Q＆A（パーソルキャリア 柿田さん）
（Q）パーソルキャリアはパーソルテクノロジーさんとかと違うんですよね。グループもデカいですが、セキュリティ関連での連携、情報共有、共通ルールなどありますか？
率直に申し上げると共通ルールなどは設けていないです。
大手のベンダーさんはカンパニー制（事業部制）が多いと思います。我々も似たようなグループ体制を取っていて、グループ会社間の情報共有はあるものの、体系化されているものではありません。
現在の運用としては、パーソルホールディングスが全てのグループ企業の情報を持っているので、必要に応じてパーソルホールディングス側に照会し、グループ会社の担当者を繋いでもらう形を取ってます。
（Q）ZTNAを小規模環境で検証したくとも、本番環境と隔離して取り組めないため進まないことにたいして、どのようにアプローチ・導入すべきでしょうか。 (予算も取りにくいため難儀しています)
実際に我々が取った手法ですが、検証用に新たに端末を数台用意し、そこからインターネット（クラウド）に出て行く部分にSWGやCASBの様にゼロトラストの代表的な機能を挟み、一定期間試行利用してます。
その際、①既存の環境には手を入れない（前述の仕組みであればクラウド側の認証でアクセス元制御が設定されていなければ実施可能。入っている場合はSWGやCASBがプロキシになるので、そこからのアクセスを暫定的に許可。尚、アカウントも検証用に新規に用意）、②試行利用期間として各部署から1〜2名で最低3ヶ月位を設け、現場で問題無いと言う評価をしてもらう、この2点を前提に弊社内は承認をもらっています。
ベンダーさんによりOK/NGはありますが、人数・期間も限定であれば、無償で評価利用をさせて頂けるベンダーさんもあるかと思いますので、そういったソリューションをまずは試されるのも一つのアプローチかと思います。
（Q）境界型からCASBを入れて、それを何ヶ年運用し、どう発展させるべきでしょうか。
実際に利用される方の人数や使うクラウドサービスのバリエーションにもよる部分が大きいですが、弊社の場合（最終的に400人位を対象として4部署宛に展開する事をターゲットとした場合）、最大20名で約半年間の試行利用を経た上で、本展開に移りました。
どうしても四半期や半期に一度といったレアな作業も現場にはあり、そういった作業も含め万全を帰した上で導入をする場合は、半年〜最長でも1年程度の試行期間があると、導入後に予期しない事態の発生は極力減らせると思います。
（Q）説明済みならすみません、CASBの費用、教えてください。
これは実際に導入する製品と、購入単位・利用期間の掛け合わせと、ディスカウント適用有無（ベンダー側目線で見た将来性の有無等）による為、ここでお答えする金額を保証出来るものではないですが、例えばCASB製品の定価ベースだと、数千円/1ユーザー(月額)で利用可能なケースが多いと思います。
（Q）CASBを入れると判断された際、リスクアセスメントの結果は考慮されましたか？またその場合、漏洩等した場合の影響はどのように評価／想定されますか？
導入に際しては、リスクマネジメント部門の担当役員も交えて協議をしています。我々の場合、CASBにより制御を行う環境ではお客様からお預かりしている個人情報は取り扱わないという大前提を設ける結論となりました。
その上で、万一取扱を許可する情報が漏洩するとした場合、それはどういう情報で、その結果どの様な事態が発生するか、例えば設計書等にはどんな情報が記載されていて、それが漏洩・悪用されるとどういう事態が考えられるのかはエンジニアがリスクと対策を整理、セキュリティ的な側面以外にも、例えば開発中で世に出す前のプロダクトの情報を持ち出し、他社で先にリリースされるとどんな損害があり、事業側としてそのリスクを許容出来るかを事業側で整理、それら踏まえて最終的にどんなリスクが残り、それを経営として許容出来るか、こういったプロセスで社内で判断をしております。
（Q）誤検知や、過検知は多かったですか？
CASBの誤検知はほとんど無かったと思います。但しEDRはかなり有りますね。なので、ここは徐々にチューニングをして行ったのと、SIEM導入後はAIベースで真にリスクのある挙動を学習してくれるので、現時点での運用負荷はだいぶ軽減されてきたと思います。
（Q）製造業やサービス業など、拠点内で事業活動する業界・業態におけるZTNAのあり方に悩みます。 クラウドは一部使えど、基本的には閉域網のネットワークでシステムは(一応)まわるため、導入の強い利点を上位層に伝えにくい。
確かに仰る通りですね。
もしそういった中で少しずつその必要性に関する啓蒙を始めるとすれば、サプライチェーン攻撃の事例に触れる所からのスタートになるかと思います。
インターネット接続がなくクラウドは利用せずともメールは利用していますという場合、確かにZTNAのメリットをフルに刈り取る事は難しいと思うのも事実ながら、標的型攻撃メールにより社内ネットワークに侵入されるケースというのは多々発生していて、そういったケースに対してはIdPのみ導入、閉域網のネットワーク内でも都度、他要素認証を含む認証が設けられていたりすると、一定被害を軽減出来るケースもあるのではないかと思います。
セキュリティQ＆A
最後にセキュリティ対策に詳しい3名のエンジニアによる質疑応答コーナーです。
勉強会当日にあがった質問に答えてくださいました！
セキュリティ担当するのに、資格は必須になるのでしょうか？（目指したい）
臼田：資格自体は不要ですが、色々と勉強しておくことはいいと思います。情報処理安全確保支援士（IPA）は基礎と応用のバランスもよくカバレッジも広いのでおすすめです。
月島：資格は必要ないですが、セキュリティも大事ですが、事業についても把握・学んでおくといいと思います。
柿田：あくまで個人的な意見にはなりますが、実務経験を客観的に第三者的に見ても担保出来る様にするのが資格だと思っています。要は実務経験の保有が第一で、余裕があれば資格を有していると尚可という様に個人としては捉えています。
セキュリティエンジニアになるまでの道程、きっかけを教えてください
柿田：キャリアの入口はインフラエンジニアで、セキュリティはその中で関連があれば取り組んだり、どちらかと言うとネットワーク周りのエンジニアリングの中で携わってきたのみでした。昨今のコロナ禍による柔軟な働き方の整備や、オリンピックの文脈で在宅勤務環境用意のニーズが爆発的になり、この辺りからセキュリティエンジニアリングが中心になっていきました。
月島：セキュリティエンジニアではないのですが、クラウド推進等やっているうえで、セキュリティは重要です。セキュリティが守れていれば安心して使えるという点で、整備への意識は高かったです。
臼田：学生の時に情報セキュリティの学科に所属したことが転機ですが、原理をたどると子供の頃からゲームの裏技が好きだったというものがあります。
情報セキュリティも脆弱性の仕組みと関連しますが、技術的な探究心（こうしたら、想定外の動きができる）が関連していると思います。
わたしはしがない情シスなのですが別部署のセキュリティエンジニアに頭があがらない。追い付きたいと思って勉強していてもどんどん最新情報変わっていくしついて行けないし、もう5X歳だしｗ
臼田：年齢は関係ないと思います。エンジニアなので、楽しいと思うところを勉強していけば、自分の推進力に繋がると思います。それは最新情報じゃなくてもよいと思います。
全部を把握、というのは誰も出来ません。私も、AWSの全部はキャッチアップしていなくて、自分の好きなセキュリティに特化してキャッチアップ・全体に共有をしています。
柿田：年齢は関係ないです。逆に様々な経験の蓄積やそれとの掛け合わせは強みになると思います。セキュリティ対策はそれ自体が目的なのではなく、事業を推進/支援する為に必要なもので、そういう意味で、もっている経験値とセキュリティの技術などの掛け合わせで他のセキュリティエンジニアには無い強みが出せるのでは無いかと思います。
一般的なクラウドサービス利用のメリットは、簡単に使えるという利点がありますが、クラウドセキュリティ関連サービスについても、同じく簡単に始められて、管理にも複雑なスキルを必要としない製品が多数ある為、そういったサービスを選定されるのを一つの判断基準にされるのも良いかと思います。
IT業界初心者はどのようにセキュリティの勉強をすればいいですか？
臼田：基礎はすごく大事です。どこかのタイミングで、基礎は必ず勉強しておくとよいです。コンピュータサイエンスの分野は様々な基礎につながっているので、コンピューターがどのような原理で動いているのか把握することは大切です。始めるポイントは自分の興味がある分野の周辺の基礎からで問題ありません。Web系ならHTTPなどのプロトコルやネットワークの原理など押さえていくといいでしょう。IT業界にいる限り、基礎は大切。範囲は広いですが、自分の分野から徐々に押さえていくのが良いと思います。
月島：どう作られているのか、などを把握していくのがいいと思います。そこに脆弱性や攻撃を受けやすいところがあると思います。そこの仕組みや関係者を探っていけるといいと思います。
柿田：ITやテクノロジー系のWebサイトをざっと見るだけでも、サイバーセキュリティや攻撃などの情報は沢山掲載されているかと思います。それを引用し、その際ほんの一言自分の見解（どういう事象で何が原因？これに対して自分はこういう対策があると思う等）を社内向けに共有するだけでも、自分の言葉で表現する為、中身を理解する事につながると思います。
やはり常に最新情報の取得は必要ですか？それを追う担当と、社内をガッチリ見る担当に分かれているチームが良いのでしょうか？
臼田：役割分担はそれぞれ得意不得意がありますのでメンバーの状況により判断するところですが、社内で協力体制を組むのはいいと思います。
月島：組織によっても異なるところですが、一極集中で情報をキャッチアップ、発信するという方法や、それぞれの役割毎でキャッチアップ、発信する方法もあると思うので、組織に合ったやり方でいいと思います。AWSなどはアップデートは多いですし、最新情報のキャッチアップはした方がいいです。
柿田：担当の分離はアサイン出来るリソースにもよる為、難しい場合もありますよね。我々の場合はSIEMを利用する事で最新のセキュリティインシデント情報は自動で取り込まれ、機械的に検知出来るようにしているので、マンパワーに頼らない状態を目指しています。
*ちなみに弊社は現在MicrosoftのAzure Sentinelを試行中です。
最新情報の取得はやはり可能な限りされることをお勧めします。日々新たな脆弱性や攻撃手法が発生し、あっという間に身内もその攻撃に晒されているというのが当たり前の世の中になってきていると思います。
進化するセキュリティ対策と、そのデータを取り扱う作業者のメンタルヘルス対策は、表裏一体だと感じました。
臼田：セキュリティの原理のひとつに、データからなるべく人を遠ざけるという考え方があります。
大事なものを扱う人に心理的負荷は少なからずかかってしまいます。なので、環境を分離して本番環境に人が直接触れないようにしたり、安心できるシステムづくりが必要だと思います。
柿田：この人、こんなサイトを参照しているの？とか、人に対する思いがデータがみえることで変わってくることがあります。またバイアス掛かった見方が時に誤った判断をさせてしまうこともあるかと思います。こういった心理的負担や判断誤りを減らすべく、極力機械的にアラートを発するようにしたり、人を介する回数を減らすという工夫をしています。
月島：とても大事なところですね。権限分掌とか、データを触っている人もちゃんとルールを守っているよという明示ができるといいと思います。
セキュリティ対策を考える際、性善説、性悪説どちらで構築していきますか？
臼田：二極的な話なので、それじゃ収まりませんが…。どちらの方面から始めるかという点では会社の状況にあわせた選択がいいと思います。例えば会社のなかで良い文化が出来上がっていて、不正が発生しづらい雰囲気であるなら性善説よりに、誤操作などでリスクを感じるところから取り組む必要がある。社員が多かったり、複雑になって管理が行き届いていないときは性悪説よりで、不正が起きやすい・起きたらまずいポイントから抑止力も含めて対策していく。大事な資産を守るという感覚はどちらも変わらないと思います。
月島：状況やシーンによります。大事な資産に触れるところで、リスクはあります。
リスクの受容も必要な時はあるので、決断が大切。どちらかで断じるのは難しいです。人はミスするという感覚で、動くといいと思います。
柿田：難しい所ですが、正直ベースでお答えすると「使い分けて」いて、社内に取り組みの内容を発信する際は性善説に立ち、理解を得られる様な説明をしていますが、実際の制御は性悪説に立って設定してます。どうしても内部犯行に対しての対策は昨今取らざるを得ず、特に多いのが悪意は無いが、リテラシー不足に起因するリスク含みのオペレーションに対して、しっかりと対策をする為、性悪説に立っての制御をしています。
臼田：セキュリティ対策は終わりがない。性悪説で捉えなければならないところもあるし、性善説でうまくリスクを受容するところも、やっていかなければ回せない。バランスを取るしかない。
SNS投稿のマナーを学ぶこともセキュリティの勉強の1歩だと思いました。
臼田：うちの会社では、仕事しながらSNS触っていても怒られません。それは常識に則った範囲ですが。ただ、危ない発言には抑止力が働くようにはなっています。SNSで発言することは匿名ではありませんから、自宅や会社の窓から全世界に向けて大声を上げている、という責任の認識は必要ですね
メンバーに是正を促す場合も、ただ良くない、と否定するのではなく、具体的な解決策を提示するようにしています。
月島：定期的にコンプライアンスのラーニングの場があります。事例を取り上げていることもあります。お客様の個人情報を取り扱っているので、そこをどうやって守るのかというところは結構厳しめです！
イベントレポートは以上となります！
次回のレポートもお楽しみに♪
