ISO27017管理策解説（クラウドサービスカスタマ）2
ここでは、ISO27017管理策の解説をしていきます。
今回は、『9.1.2 ネットワーク及びネットワークサービスへのアクセス』～『10.1.2 鍵管理』まで解説します。
目次
※ ご覧になりたい項目をクリックすることで、該当のセクションにジャンプできます。
9.1.2 ネットワーク及びネットワークサービスへのアクセス
ISMSの取り組みで資産の洗い出しを実施した時に、その資産の閲覧範囲を同時に決定した会社が多いのではないでしょうか。
例えば、人事考課情報は、おそらく経営陣と人事部しか閲覧できないでしょう。
ところが、その人事考課情報を保管しているクラウドサービスのアカウントを全員が所有していて、その情報にアクセス可能となっていれば、本末転倒です。
そのようなことがないように、組織が利用しているクラウドサービスにアクセスできる従業者は十分に検討すべきです。
クラウドサービス特有の問題として、「アカウントの発行が、社内の担当者を通さずとも比較的簡単に出来てしまうケースがある」ことが挙げられます。
利用者が「あ、そういえば、Aさんがアカウント欲しそうだったので、発行してあげました」あるいは「パスワード共有して使っています」みたいなことが発生しないように、適切な管理をしていくことが求められています。
9.2.3 特権的アクセス権の管理
特権アカウント(いわゆる「管理者ユーザー」など)は、一般ユーザーよりも強い権限をもっています。
さらに、クラウドサービスの特徴としてどこからでも、いつでもアクセスできることから、特権アカウントに関する認証情報(ID、パスワードなど)が流出してしまうと、大きな被害が想定されます。
幸いなことに、最近の認証技術の進歩により、パスワード以外の要素を認証に利用することで、パスワードを紛失しても不正ログインされない仕組みが整備されつつあります、それが「多要素認証」です。
よくある「多要素認証」の方法は、ログインしようとすると、スマホのSMSに数字のコードが届いて、そのコードを入力することで、初めてログインできるという方法です。この方法を用いると、たとえパスワードをなくしても、スマホを同時に同じ場所でなくし、かつスマホのパスワードを突破されない限り、ログインされません。
このように、クラウドサービスを特権アカウントで利用する場合には、多要素認証など、十分に強い認証の仕組みを利用することが求められています。とはいっても、クラウドサービス提供者側が、多要素認証をサポートしていないと、多要素認証を導入することが出来ません。
規格には「特定されたリスクに応じ」と書かれているので、可能な範囲でできる対策を講じていくのが良いでしょう。場合によっては、クラウドサービス提供者側に、追加機能のリクエストを送ってみても良いかもしれません。
9.2.4 利用者の秘密認証情報の管理
あなたの会社のパスワードルールはどのようなものでしょうか？
代表的なものとして、「初期パスワードは必ず変更する」「桁数は8桁以上」「英数混在」「同じパスワードを複数サービスで使いまわさない」「パスワードは付箋など、紙に書いてはいけない」といったルールを定めている会社が多いのではないでしょうか。
ところで、これらのルールはクラウドサービスを利用する場合でも同様に適用されるはずです。しかし、肝心のクラウドサービス側が、自社が定めたパスワードルールを満たせない仕様だった場合はどうでしょうか。
そのような事態を避けるために、この管理策では、自社のパスワードに関するルールが、クラウドサービス上でも適用できるのかどうかを、事前に確認しておきましょう、ということを述べています。
もちろん、自社のパスワードルールが適用できないからといって、即「このクラウドサービスは利用禁止」となるわけではありません。その場合は、リスクが許容範囲に収まるか、あるいは受容するのかどうかを十分に検討し、必要に応じて追加のセキュリティ対策(IPアドレスによるログイン制限など)を実施すべきでしょう。
クラウドサービスによっては、一般ユーザーが設定するパスワードポリシーを、管理者ユーザーが設定できる機能も存在しています。そのような機能があれば、積極的に利用していくべきです。
9.4.1 情報へのアクセス制限
一概に「情報へのアクセス制限」といっても、その方法はたくさんあります。
例えば、そもそもその情報が保管されているクラウドサービスのアカウントを付与しないこともアクセス制限ですし、その情報を見ることができる機能にアクセスさせないこともアクセス制限です。
また、その情報自体の閲覧権限を狭めることも、アクセス制限の手法です。
ところで、9.1.2でも述べましたが、組織の情報の中には、閲覧範囲が定められている情報が多くあります。
そのような情報に対して、クラウドサービス上でもしっかりとアクセス制限を実施できるようにしましょう、というのがこの管理策の意図しているところです。
9.1.2は、「サービスに対する」アクセス制限でしたが、この9.4.1は、「各情報に対する」アクセス制限のニュアンスが強いです。場合によっては、この2つの管理策は同時に検討しても良いでしょう。
9.4.4 特権的なユーティリティプログラムの使用
もし、クラウドサービスの中に「なんでもできちゃう機能」があれば、その機能の利用を制限しましょう、というのが、この管理策の意図するところです。
例えばデータベースの中身を、その整合性を気にせずに強制的に書き換えることが可能な機能や、各ユーザーになりきって、そのユーザーの権限で色々操作できてしまうような機能が考えられます。
通常の一般的なWebサービスの場合は、このような「なんでもできちゃう機能」は、危険な機能のため、機能自体が存在していない場合が多いです。
しかし、IaaSの利用を考えてみると、サーバの管理者権限は、基本的に制限を無視して「なんでもできちゃう」ため、1つの特権的ユーティリティプログラムと考えることができます。
そのような機能の利用を、パスワードなどで保護し、特定の人間しか利用できないようにすることは、ここで求められている対策の1つになります。
10.1.1 暗号による管理策の利用方針
クラウド上のデータに限らずですが、データが存在する限り、外部に流出してしまう可能性はあるため、重要なデータは暗号化し、万が一流出したとしても、元のデータがわからないようにしておくことは大切です。
ここでは、そのような、「組織が暗号化すべきと判断した重要なデータは、クラウド上でも適切に暗号化されていることを確認しましょう」といったことが求められています。
「クラウドサービス内に保管したデータは適切に暗号化されています」ということを確認するだけでは不十分です。クラウドサービスへのアクセスは、多くの場合、インターネットを経由することを忘れてはいけません。保管されているデータだけでなく、通信経路もSSLの導入などで適切に暗号化されていることを確認しましょう。
また、更に言うならば、そのクラウドサービスが外部APIなどの別のクラウドサービスを利用している場合、可能であれば、その経路も暗号化されていることを確認すべきです。
10.1.2 鍵管理
クラウドサービス上でデータを暗号化している場合は、何らかの暗号鍵が存在しているはずです。その暗号鍵の管理が、クラウドサービス側で実施しているにせよ、自社で実施しているにせよ、管理方法を明確にし、自社の鍵管理ルールに整合しているかを確認する必要があります。
もし、鍵がクラウドサービス側で管理されている場合は、鍵の保管や更新が適切に実施されているか、鍵の種類や長さは十分なものであるか、などを確かめておくべきでしょう。また、もし仮に、鍵を自社で管理する場合は、その復号鍵は、同じクラウドサービス上に保管しないようにすることも大切です。
暗号化された情報の流出と同時に、その暗号を複合できる鍵が同時に流出してしまえば、暗号化の意味が無いからです。
取得される企業様の状況によって変わりますので、まずはお気軽にご相談ください。
