頻発するクラウドインシデントを防ぐ「だろう」運用と対策

クラウドでインシデントが起きると情シス担当者の評価に大きく影響します。今回はこうしたクラウドのインシデントを整理し、どのような対策ができるかについてお話しします。

[久松 剛，エンジニアリングマネージメント]

情シス百物語

「IT百物語蒐集家」としてITかいわいについてnoteを更新する久松氏が、情シス部長を2社で担当した経験を基に、情シスに関する由無し事を言語化します。

　クラウドにまつわるインシデントが相次いでいます。社内には個人情報をはじめ重要情報が多いため、従業員のちょっとした作業ミスで情報が漏えいし、その影響で経営が傾くこともあります。

　また、インシデントによって「クラウドは危ない」といった認識が、ITに明るくない経営層に広がることもあります。経営層が安全と認識しているクラシカルな方法に戻すことにで運用コストなどが大幅に増大することもあります。

　クラウドのインシデントが起きると情シス担当者の評価にも大きく影響します。今回はクラウドに関するインシデントを中心に整理し、どのような対策ができるかについてお話しします。

頻発するクラウドのインシデントを振り返る

　まず、近年のクラウドのインシデントを振り返ります。

クラウドストレージの設定不良によるもの

　労務管理クラウドサービスのユーザー情報が外部から閲覧可能になっていた問題です。

　16万2830人分の情報が閲覧可能になっていた上、15万4650人分の情報が第三者にダウンロードされたと発表されています。漏えいした情報は氏名や性別、住所、電話番号、身分証明書、履歴書の画像などです。これらの情報が保存されたストレージサーバにアクセス権限の設定ミスがあったと報告されています。

オンラインストレージの設定不良によるもの

　「Googleドライブ」の情報公開設定にミスがあり、顧客や取引先、退職者など93万5779人の情報を含むファイル1369件が誰でも閲覧できる状態だったという報告です。漏えいした情報は、サービス利用者や法人顧客、採用候補者などの氏名、メールアドレス、住所、電話番号と発表されています。

　前者がクラウドストレージの設定という管理者権限が必要なものであるのに対し、後者は管理者の設定によっては従業員に権限が与えらえていたという異なる側面があります。

インシデントを防ぐ「だろう」運用と対策

　こうした事故は、ハッカーなどに攻撃され情報が盗られてしまったものとは様相が異なります。機密情報を誰でも見れてしまう状況にしてしまったという過失の要素が強いです。そこで思い出すのが下記の出来事です。

　私がIT業界に出入りしはじめた2000年ころ、インターネットの広さと恐ろしさを感じたニュースが、2001年のCode Red、Nimdaというコンピュータウイルスの登場です。それまではITネットワークの専門家であっても「ファイアウォールは甘え」「やられるような設定をする管理者が未熟」という話すらあったのですが、OSセットアップ中のPCが感染するようになるとネットワークファイアウォールを導入しなければならないという認識に変わりました。

　クラウドセキュリティも似たような側面があり、「一時的にインターネット全体に公開したら、アクセスされるだろう」という「だろう」運用が必要と考えています。

クラウドストレージにはCSPMの導入検討

　クラウドストレージはCSPM（Cloud Security Posture Management）の導入が広がっています。セキュリティリスクの低減を目的に、クラウドサービスの設定を継続的に評価したり、セキュリティリスクにつながる設定や状態を検出したりする機能があります。

　クラウド事業者が用意しているものもあれば、セキュリティ企業が提供しているものもあるので、求めるセキュリティレベルと内容に応じて選定するようにしましょう。

オンラインストレージにはアクセス権の設定を

　オンラインストレージに関するインシデントは社内全体に影響が広がるため、セキュリティポリシーの見直しや適用が頻繁にされる傾向があります。セキュリティポリシーが非常に厳しい場合は外部共有を全てオフにすることも考えられ、そうした企業も多数存在します。

　しかし外部とのコラボレーションが多く発生する業態では、必ずしも最適解と言えません。直接Facebookの「Messenger」などでファイルが送られてきたり、GoogleやMicrosoftの個人アカウントでファイルをやりとりしたりするケースもあります（GoogleWorkspace、Microsoft365のファイル共有の詳細）。企業によっては、ファイルのコピーがファイル転送サービスの提供元に残るものを奨励してしまっています。

　抜け穴を作られ別の懸念が発生するのであれば、次に述べるような代替案を採用するのもよいでしょう。

監査ログの記録を有効にする

　ユーザーの操作記録を保存する、監査ログの設定を有効にすることをお勧めします。なにかトラブルが発生した際、監査ログを基に誰が何をしたのかをさかのぼることは非常に有効な手助けとなります。

　監査ログなしでは問題が起きたときの現況を追求しにくく、それらしき人を見つけたとしても証拠がなく、本人も「知らぬ存ぜぬ」で通す可能性が高いため、問題の特定に時間がかかります。

　インシデントはいつ起きるか分かりません。可能な限り監査ログは有効にしておきましょう。最終的には従業員やご自身を守ることにつながるでしょう。

セキュリティ教育の実施

　座学での講習が有効です。何が個人情報に当たり、何が違うかを理解してもらうことから、自社で禁止している項目を認知してもらうことまでがゴールです。

　自社で情報漏えいが起きた際の影響範囲を想像してもらえる内容にすると、より親身に聞いてくれます。私がセキュリティ教育を実施する際は、他社のセキュリティニュースや自社の危うかったことなどをコンテンツにすることで、興味引くようにしました。

　セキュリティ教育はオンラインでの動画受講と、理解度チェックテストを実施している企業が増加している印象です。理解度チェックテストでは、「Google Form」などの機能を使って採点までしてしまう企業がありますが、誰がどうやっても100点になるので無意味です。お勧めはオフラインでの開催です。私の経験上、ここで寝ている人は何かしらのインシデントを起こすので目を付けておくとよいでしょう。

インシデントのあった企業へ転職するという選択肢

　最後に視点を変えて情シスのキャリアについてです。重いインシデントがあった企業にあえて転職する方がいます。経営基盤が盤石で、インシデントがあっても事業を保っているだけでなく、ある程度の覚悟を持ってシステムや従業員教育をコストをかける企業であれば、泥臭く過酷な作業もありますが関わってみることをお勧めします。

　個人的にもこうした情シスに何度かお会いしたことがあります。実施した改革について所属組織がバックアップした上でセミナー講演をしたり、次の転職をした時に「あのインシデントから組織を立て直した人」という見え方をしたりすることで市場評価が上がります。

　あくまでも「立て直し」をした人で、「インシデントの当事者ではない」という時系列を強調する必要はありますが、箔が付くお勧めのキャリアの一つです。

著者プロフィール：久松 剛（エンジニアリングマネージメント　社長）

　エンジニアリングマネージメントの社長兼「流しのEM」。博士（政策・メディア）。慶應義塾大学で大学教員を目指した後、ワーキングプアを経て、ネットマーケティングで情シス部長を担当し上場を経験。その後レバレジーズで開発部長やレバテックの技術顧問を担当後、LIGでフィリピン・ベトナム開発拠点EMやPjM、エンジニア採用・組織改善コンサルなどを行う。

　2022年にエンジニアリングマネージメントを設立し、スタートアップやベンチャー、老舗製造業でITエンジニア採用や研修、評価給与制度作成、ブランディングといった組織改善コンサルの他、セミナーなども開催する。

Twitter : @makaibito