2. ISO27017管理策解説（クラウドサービスプロバイダ）
ここでは、ISO27017管理策の解説をしていきます。
今回は、『8.1.1 資産目録』～『9.4.4 特権的なユーティリティプログラムの使用』まで解説します。
目次
※ ご覧になりたい項目をクリックすることで、該当のセクションにジャンプできます。
8.1.1 資産目録
「クラウドサービスカスタマデータ」と「クラウドサービス派生データ」の2つを洗い出すことが求められています。
2つのデータの洗い出しと管理
1つ目の「クラウドサービスカスタマデータ」は何となく分かりそうですが、2つ目の「クラウドサービス派生データ」と言われてピンとくる方は少ないのではないでしょうか。
「クラウドサービス派生データ」とは一体何かと言いますと、用語集であるJIS X 9401にしっかりと記載されています。代表的な例は、JIS X 9401にも書かれていますが、「ログデータ」です。ログデータ以外にも、利用者がサービスを利用するために必要な設定情報や、利用者が投稿したコンテンツに紐づくメタデータ（投稿者、投稿日時など）が、派生データに該当します。
誤解を恐れずにシンプルに言ってしまうならば、「利用者が意図せずに、クラウドサービス上で生成されてしまうデータ」のことです。
そのようなデータを、自社の資産と同様に目録に洗い出し、適切に管理することを求めています。
自社の資産目録に追加する形で作成しても良いですし、別の新しい資産目録を作っても良いでしょう。
8.2.2 情報のラベル付け
クラウドサービスの提供に伴い、利用者から預かるデータは様々です。
その中でも、利用者が「タグ付け」や「ラベル付け」などを実施することにより、
データを適切に分類できたほうが、利用者のセキュリティレベルが向上するだろうと思われるケースがあると考えます。
例えば、利用者がクラウドサービスにアップロードしたファイルを、すべて一覧で表示できる機能があったとしましょう。そのファイルにラベル付けができれば、利用者の情報管理の手助けになるケースもあるでしょう。
そのような、タグ付け・ラベル付けなどにより、利用者の情報分類の役に立つようなケースがある場合は、その機能を実装し、提供することが求められています。
そして、そのタグ付けやラベル付け機能の使い方は、サービスのWebページやFAQなどにまとめて、利用者が使いやすい状態にしておく必要があります。
9.2.1 利用者登録及び登録削除
会社によっては、退職者が発生したときに、その退職者のアカウントの削除ルールが厳しく決められている場合があります。
例えば、Aさんが退職した時、Xサービスのアカウントは退職日に削除、Yサービスのアカウントは管理部でパスワードを変更し、1ヶ月後にアカウントを削除、などです。
ところで、外部のクラウドサービスを利用している場合には、この要件が叶わない事があります。
一例として、「アカウントの削除は所定のフォーマットの申請書を提出して下さい、3営業日以内に削除します」といったルールが定められたクラウドサービスがあったとします。
その場合、利用者は最大3営業日の間、退職者のアカウントを削除することができなくなってしまいます。
上記のような事態を避けるために、クラウドサービスの提供者は、利用者に対し、アカウントの登録や削除に関する機能の提供と、その機能を利用するための仕様や手順書を提供する必要があります。
具体的に利用者に提供しなければいけない情報とは
具体的に、どういった情報を提供すれば良いのかは規格には書かれていませんが、経産省のガイドラインを見ると、「アカウント登録削除の手順」「アカウント登録削除に必要な情報」「利用者の同一性検証の仕様」など、いくつかの例が挙げられています。
なので、上記の内容を、あらかじめ利用者に開示しておく必要があると考えることができます。
(2) アカウントは、管理者ユーザーであれば、いつでもお好きな時間に、お好きなタイミングで管理画面から登録・削除が可能です。
9.2.2 利用者アクセスの提供
サービス上において、いわゆる「アクセス権」を管理する方法はいくつもあります。
ユーザーを幾つかのグループに分け(例：人事部)、そのグループ単位でアクセス権を付与する方法、ユーザーごとにアクセス権を付与する方法、アクセス権をまとめたロール(役割)を作成し、そのロールを各ユーザーやグループに付与する方法、などです。
ユーザーの権限を適切に設定する
この管理策では、そのような、アクセス権を管理する方法(ユーザーのグルーピング、ロールの付与など)を、利用者側の管理者ユーザーが自由に利用し、設定できることを求めています。
ややこしいことを言いましたが、結局のところ、多くのクラウドサービスは「管理者ユーザー」と「一般ユーザー」でまず権限が分かれており、権限ごとに閲覧可能な情報(アクセス権)は異なっているはずです。
そして、「管理者ユーザー」は「一般ユーザーを管理ユーザーにする」ことも「管理者ユーザーを一般ユーザーにする」ことも可能です。これが可能ということは、アクセス権を管理する最低限の機能が、利用者に提供されていることになります。あとは、これらの機能を利用するために必要な仕様や手順書が提供されていれば、この管理策で求められている最低限のラインはクリアできるでしょう。
9.2.3 特権的アクセス権の管理
通常のクラウドサービスの認証(ログイン)は、ID(もしくはメールアドレス)とパスワードの2点セットだと思いますが、規格では、特権アカウントの認証には、多要素認証を始めとした十分に強い認証技術を実装することを要求しています。
ただ、必ずしも多要素認証の実装が必要なわけではありません。規格には「クラウドサービスカスタマが特定するリスクに応じた」と書かれているため、クラウドサービスの利用者側が不安に感じている不正ログインのリスクを払拭できる認証技術を用いていれば大丈夫です。多要素認証以外の例としては、例えば、パスワードポリシーを強固なものにする(英数記号混在の12桁以上など)や、ログイン時のIPアドレス制限を行う、なども選択肢として考えられます。
9.2.4 利用者の秘密認証情報の管理
この管理策では、利用者に対して、「秘密認証情報の管理のための手順」を提供することが求められています。
「管理のための手順」とは、例えば、新規登録時や、パスワード変更時に、利用者にパスワードを割り当てる手順などが該当します。クラウドサービスを初めて利用する場合は、多くの場合「初期パスワードの発行」が行われますが、
そのパスワードの設定方法には様々な手法があります。
例えば、サービス利用者側の管理者ユーザーに、利用者の初期パスワードがまとめて通知され、それを、オフィスなどで物理的に利用者に配布する方法や、利用者のメールアドレスに自動的に通知される方法などです。
自社が提供しているクラウドサービスのパスワード配布のルールによって、サービス利用者が取るべきセキュリティ対策は異なってきます。よって、あらかじめ利用者に対して、パスワードの登録、変更、再発行の手順を公開しておくことが大切です。
9.4.1 情報へのアクセス制限
9.2.2では、利用者がアクセス権を自由にカスタマイズできる仕組みの提供を求めていますが、ここでは、そのアクセス権が設定できるセグメント等を検討し、提供することが求められています。
権限の種類を決定する
いくら利用者がアクセス権を自由に設定できるとしても、一般ユーザーと管理者ユーザーの2つの権限しか無いクラウドサービスの場合、利用者にとっては、情報へのアクセス制御が十分に行えない可能性があります。
クラウドサービスの種類によっては、閲覧だけが可能な「ゲストユーザー」などが必要となるケースもあるでしょう。
この管理策では、クラウドサービスの提供者の責任として、自社が預かる、つまり、利用者がサービス上に保管する情報を鑑みて、どのセグメントでアクセス権を切るのかを検討し、利用者に提供することが求められています。
ちなみに規格では、アクセス権の切り方として、サービスへのアクセス権、機能へのアクセス権、データへのアクセス権の3つが例として挙げられています。サービスへのアクセス権とは、サービスを利用するために何らかの認証があること(これは当たり前かもしれません)を意味しています。
9.4.4 特権的なユーティリティプログラムの使用
自社のサービスの管理の利便性を向上させるために、通常ならば適切な認証手順を経なければ利用できない機能や動作を、その認証をかいくぐって利用できるように、カスタマイズをしている場合があります。
イメージ的には、「本来は～しなきゃできないんですけど、～するとできちゃうんですよ」などと言った機能です。意図的に仕掛けたサーバのバックドアや、承認を得ていない一時的なポートの開放などがそれにあたります。
そのような運用をしている場合は、全て特定し、運用そのものに問題ないかどうか精査する必要があります。問題があれば、利用を停止する必要がありますし、もし問題がないと判断されるか、業務上止むを得ない事情で、引き続きその運用を続ける場合は、その機能にアクセスできる人間を、可能な限りで最小化し、利用のログを取り、定期的にログを確認(監査)することが求められています。
取得される企業様の状況によって変わりますので、まずはお気軽にご相談ください。
