クラウドセキュリティ管理基準の策定〜実装〜運用で得た気付きとポイント：失敗、成功事例に学ぶクラウドネイティブセキュリティの勘所（3）

クラウドセキュリティに対する不安からクラウド移行に踏み切れない企業や、クラウド移行したもののクラウドセキュリティに依然として懸念がある企業に向けて、クラウドで実現するセキュリティ対策を事例とともに解説する本連載。今回は、クラウドセキュリティ管理基準の策定〜実装〜運用で得た気付きとポイントについて。

[村田紗矢子，キンドリルジャパン]

　クラウドセキュリティに対する不安からクラウド移行に踏み切れない企業や、クラウド移行したもののセキュリティに依然として懸念がある企業に向けて、クラウドで実現するセキュリティ対策を事例とともに解説する本連載。今回は、クラウドセキュリティ管理基準の実装から運用について、事例とともに留意点を解説します。

　本稿では、顧客環境や自社の共用インフラ環境において、クラウドセキュリティ管理基準の策定から実装、運用に至るまでさまざまなフェーズで関わってきた筆者の経験を基に、その事例およびポイントを解説します。

クラウドセキュリティ管理やガバナンスに関する課題認識

　既に各事業部や部門でクラウドの利活用が進んでいる一方で、クラウドサービスの利用指針や管理基準の策定、管理態勢の整備が追い付いていないと感じている企業も少なくないと推察します。管理基準がない、または管理態勢の構築がまだ十分でない顧客を担当したときの気付きを2つご紹介します。

　1つ目は、企業としての一定の基準がないことから、各組織やチームの意識や認識の差で、セキュリティの取り組みレベルに差が生じていたことです。そのため、セキュリティに関する意識が低い部門が利用しているサービス経由でセキュリティ侵害が発生しかねない状態でした。

　2つ目は、クラウドに関する管理基準がなく、PDCAサイクルがスタートできていないことから、課題を整理できていないことです。経営層やITセキュリティ部門が漠然とした不安や懸念を感じており、「なんとなく不安」や「いつかうちもA社と同じようなことが起きるのではないか……」といった課題意識はお持ちでした。しかし、課題が整理できていないため、クラウドセキュリティの取り組みが進んでいませんでした。

　このような気付きを踏まえ、クラウドセキュリティに関する管理基準の策定、実装、運用におけるポイントを紹介します。

クラウドサービスの利活用における管理体系、管理態勢整備の重要性、その理由

　本題に入る前に、クラウドサービスの利活用において、管理体系および管理態勢の整備がますます重要になっている理由を整理します。

　これまで、オンプレミスであればシステムの主管部門はIT部門にとどまっていましたが、クラウドサービスは管理主体が各ユーザー部門にも広がりつつあります。そのため、基盤チームやアプリケーション部門といったIT部門の範囲を優に超え、全社的にクラウド利用に関するガバナンスを効かせる必要が出てきました。ますます会社としてクラウドサービスに関する管理基準を持つ重要性が高まってきたと考えます。

　クラウドセキュリティの管理基準があれば、それをベンチマークとして社内点検を実施し、現在の立ち位置を把握、改善に向けたPDCAサイクルを回すことができます。しかし、目標となる基準がないとそもそもそのサイクルを回すこともできません。そのため、このような土台作りがクラウドセキュリティにおいても重要です。

クラウドセキュリティ管理基準の策定〜実装〜運用に関わって得た気付き

　クラウドセキュリティ管理基準の策定〜実装〜運用に関わって得た気付きとして下図にある3つのレイヤーを紹介します。

クラウドサービス利用に関する基本方針

　一番上の「クラウドサービス利用に関する基本方針」は経営層が企業としてのクラウドの利活用の方針を指し示すものです。クラウドセキュリティの管理基準策定に当たっては、会社としてのクラウド利活用の方針を明確にし、経営課題やビジネス目標とリンクさせることが大変重要です。

　日本政府が推進する「クラウド・バイ・デフォルト原則」も基本方針の一つの例といえるでしょう。

クラウドセキュリティ管理基準

　中段の「クラウドセキュリティ管理基準」は、元からあった既存の管理基準（つまりオンプレミスベースの基準）に別章として作成して同じ文書に取り込むケース、既存の基準と親子関係を保ちつつも別冊として作成するケース、あるいは完全に独立して作成するケースがあり、組織にあった文書体系を選択する必要があります。

　経験上、より重要だと感じているのはIaaS/PaaSとSaaSに求める基準ははっきり書き分けて区別することです。各部門や組織に展開した際に混乱を招きにくく、かつ浸透しやすいです。

　また全てのクラウドサービスに同一基準を適用することはコストの面からも現実的ではありません。業務の重要度や情報の機密区分によって、適用すべき管理コントロールを書き分けた方がよいと考えます。

　さらに、クラウドセキュリティ管理基準の作成方法として、世の中でスタンダードやガイドラインとされている「ISO27017」やFISC（The Center for Financial Industry Information Systems：金融情報システムセンター）ガイドラインを参考に作成する方法もありますし、クラウドサービス特有のリスクをあらためて洗い出して整理し、自社に与える影響を踏まえて策定するアプローチもよいでしょう。

　コンサル部隊と一緒に作成する場合は、この機会に想定されるさまざまなリスクをディスカッションしましょう。また忘れてはならないのが、クラウドサービスの責任共有モデルを意識して自社の実施範囲を明確にする点です。

設計、設定基準

　中段下の「設計、設定基準」の中でも、セキュリティ設定基準については「CIS Benchmark」などの世の中で広く使われているセキュリティパラメーターのベンチマークをベースに、それぞれの企業または組織で作成することを推奨します。ここで設定したゴールが、CSPM（Cloud Security Posture Management）のベースにもなります。

プロセス文書

　下段の「プロセス文書」は、オンプレミスで使用していた文書から内容を引き算し、クラウド固有部分を追加する方法で問題ないと考えます。また、クラウド利用開始時の認可プロセスは、SaaSについては特に企業、組織において非常に重要なコントロールポイントになるため、新規に作成、整備すべきでしょう。

クラウドセキュリティを支えるツール群

　次に「クラウドセキュリティを支えるツール群」には、CSPMやCWPP（Cloud Workload Protection Platform）、最近ではSSPM（SaaS Security Posture Management）、CIEM（Cloud Infrastructure Entitlement Management）などがあります。

クラウドセキュリティもPDCAサイクルで継続的に改善が必要

　これまで紹介した文書やツールを整備して運用管理を進めていくわけですが、クラウドセキュリティ管理基準を基に、利用フェーズごとのチェックリストを作成することもお勧めです。利用者の自己点検に利用したり、組織の第三者点検などに活用したりしましょう。それこそがPDCAサイクル開始の第一歩です。

　最終的にはクラウドセキュリティについて下図のようにPDCAサイクルを回し、継続的に改善することが重要ですが、まずはこちらをスタートできる状態にしましょう。

　チェックの部分は、ツールによる自動化も手動点検もどちらも必要だと考えています。うまく両方を併用し互いの足りないところを補いながら継続的に確認、是正するとよいでしょう。

クラウドならではのセキュリティ運用項目のご紹介

　次にクラウドならではのセキュリティ運用項目をご紹介します（※オンプレミスと同等のセキュリティ運用項目は入れていません）。

1.クラウドポータルの特権定期棚卸し

　クラウドポータルの権限は、通常のOSやミドルウェアのように、ずばりどれが特権なのかが分かりません。そのため、個々の組織で事前に特権相当の権限を定義することが必要です。

　特権操作用のIDと参照系のIDを用意し、操作目的に応じて使い分けるようにしましょう（必要時のみ特権IDを使用することで、誤操作によるインシデントを軽減できます）。

2.サービスアカウントの定期棚卸し

　ユーザーIDの定期棚卸しの対象を、個人が使用するユーザーIDに限定せずに、手動で作成したサービスアカウントも加えるべきでしょう。いざ棚卸しをしてみると、用途不明だったり、テスト目的で一時的に作成した後放置されたりしているサービスアカウントも散見されます。「用途不明、所有者不明のサービスアカウントは怖くて消せない」といった事態にもなりかねませんので、台帳やコメント欄を活用して、用途や所有チームを明確にしましょう。

3.GitHubなどのコードリポジトリやAnsible Towerなどの自動化ツールのID定期棚卸し

　インフラのコード化が進む昨今、ユーザーIDの棚卸し対象として、サーバのIDに加え、「GitHub」などのコードリポジトリの利用ユーザーや「Ansible Tower」などの自動化ツールの利用ユーザーも加えましょう。またGitHubなどに平文でパスワードやAPIキーを書かないように周知を徹底しましょう。

4.APIキーの定期更新

　定期的にAPIキーを変更することがだいぶ浸透してきたと思いますが、2020年ごろ、セキュリティ担当として関わったとある案件では、構築チームにそのルールの浸透、徹底が十分でなかったために、サービスイン後APIキーの使用ログから一つ一つの利用箇所を特定し、さらに数カ月モニタリングした上で問題が生じないことを慎重に見極めながら変更したという経験があります。

　APIキーを定期的に更新できるよう、どこで使われているか、事前に押さえてくことが大変重要です。

　次に、ユーザーID管理以外のセキュリティに関して取り組んでいた運用項目を幾つか紹介します。

1.仮想ストレージの公開設定検知と是正運用

　最近では、CSPMなどのソリューションも仮想ストレージの検知に対応しつつあります。数年前に担当した案件では、某社のセキュリティ管理基準にはまだ含まれていませんでしたが、仮想ストレージの設定ミスを起因とする情報漏えい事故が当時世の中で数多く報告されていました。そのため監視設定を施し、セキュリティチームがアラートに従って詳細を確認する運用を設計しました。

2.仮想ファイアウォールの通信ルールの定期棚卸し

　通信ルールの管理はもはやネットワーク機器だけの話ではありません。仮想ファイアウォール、つまりクラウドのACL（Access Control List）、Security Groupのルールを定期的に棚卸ししましょう。もちろん前提として通信要件を明文化しておくことが必要です。

こちらも数年前になりますが、意図せず仮想サーバをインターネットに公開してしまい不正アクセスにつながった事案が増加しつつありましたので、顧客の基準に取り込まれる前に先んじて運用に追加していました。

3.クラウドポータルで設定する範囲のセキュリティ設定維持管理

　パブリッククラウドの特性上、クラウドポータルの誤設定は大きなセキュリティ事故につながりかねません。クラウドポータルの設定値を随時、定期的に確認し速やかに是正するCSPMの取り組みはますます重要となってきています。

　kyndrylのアウトソーシングビジネスでは、サーバOSやミドルウェアのセキュリティ設定を定期的に点検する作業は浸透していたのですが、クラウドポータルの設定についてはさらに頻度を上げ確認し、緊急性が高い事案はセキュリティ担当へ通知する設定、運用を追加しました。

クラウドで特に強化が必要な項目

　次にクラウドで特にセキュリティ強化が必要な項目を紹介します。以下に挙げたものは、昨今はオンプレミス／クラウドにかかわらず必要とされていますが、クラウドの性質上＆構成上、境界防御という策は取れなくなっています。特に強化が必要な項目をピックアップしました。

1.なりすまし防止対策を強化する

　多くのクラウドサービスはインターネットから使用することが前提のため、多要素認証を導入し、パスワード桁数を増やし、複雑性を強化しましょう。

2.セキュリティパッチの適用頻度を上げる

　設計の際に、パッチが適用しやすい構成やサービス仕様にして月に1回は保守日を確保するようにしましょう。

3.定期的な脆弱性スキャンの実施と是正

　少なくとも月1回は脆弱（ぜいじゃく）性スキャンを実施し、検知事項を是正しましょう。スキャン実施時に多少負荷がかかるため、事前に定期的に実行可能な日時を調整、定めておくとよいでしょう。

4.暗号鍵の管理の強化、鍵の更新運用

　IaaS、PaaS、SaaSのどの形態においても、データの管理／保護の責任はクラウドサービス利用者にあります。データを暗号化する際に使用する暗号鍵について、クラウドサービス利用者側で管理すべきことを押さえ、プロセスや手順、運用項目を明確にしましょう。

おわりに

　これまで紹介してきた内容に加え、コンテナ環境がある場合は、コンテナ基盤環境のセキュリティ維持管理や、コンテナイメージの脆弱性管理など、実施事項がさらに増えていきます。

　お金と人手をかけて完璧を目指すのもよいですが、一方でコストやワークロードも組織にとっては懸案事項となってきます。セキュリティリスクとコストのバランスをうまくとることが求められている中で、「ガードレール戦略」や「ランディングゾーン」という考え方、仕組みは非常に理にかなっていると考えています。今回紹介した内容を踏まえながら、ガードレール戦略やランディングゾーンを検討することもポイントになるでしょう。

　本稿が、クラウドセキュリティに関して悩んでいる読者の皆さまのヒントになれば幸いです。

筆者紹介

村田紗矢子

キンドリルジャパン　セキュリティ＆レジリエンシー事業部　リスク＆コンプライアンス製造流通担当部長　シニアITスペシャリスト

セキュリティの施策を実際に現場に展開する上での計画策定・設計や運用時の改善リードなどを強みとする。設計、構築フェーズだけでなく、実際に長く運用に関わることも多く、近年ではこれまでの経験を生かして、アウトソーシング以外のお客さまに対してもセキュリティの専門家として支援している。

• セキュリティスペシャリストとして、金融セクターを中心に複数のアウトソーシングのお客さまのセキュリティ運用体制構築、管理に20年以上従事
• IBM/Kyndryl Japanグループ全体でのGlobal/Japanセキュリティ施策の展開、順守確認、各アウトソーシングプロジェクトの支援に15年以上従事
• 海外（中国）でのセキュリティ管理オペレーション拠点の立ち上げ実施
• CISSP／CISA／CISMを保持