ISO/IEC 27017 がクラウドを使う側と提供する側に求めるアカウント管理

ISO/IEC 27017 は、クラウドサービスの情報セキュリティ対策の手引です。ISMS の管理策(対策の項目)の手引である ISO/IEC 27002 に、クラウドに特有の手引と管理策を足したものです。サービスを使う会社(規格の語ではクラウドサービスカスタマ。以下、利用企業)と、提供する会社(クラウドサービスプロバイダ。以下、事業者)の両方に向けて書かれています。アカウント管理の手引は、管理策ごとに利用企業と事業者のどちらに向くかが分かれます。パスワードの管理(9.2.4)では、利用企業は事業者の手順が自社の決まりに合うかを確かめます。事業者はその手順の情報を出します。この 2 つが対になっています。

認証の基準ではなく手引である

日本語版の JIS Q 27017:2016 は、ISO/IEC 27017:2015 と内容が一致する規格です。その序文は、この規格の指針は JIS Q 27002 の指針に追加して補うものだと書いています。どの管理策を選ぶかは、リスクアセスメント(どこにどんな危険があるかの見積もり)と、法令や契約などの求めで決まります。ISMS 全体の仕組みは ISMS とはにまとめています。

日本では、ISMS-AC(情報マネジメントシステム認定センター)の制度として「ISMS クラウドセキュリティ認証」があります。規格そのものは手引で、認証の審査には JIPDEC が定めた JIP-ISMS517 を使います。ISMS-AC が認めた認証機関が、ISMS 認証に加えて 27017 の管理策が導入・実施されているかを審査します。対象は ISMS 認証を持つか取る組織で、立場は利用企業・事業者・その両方のどれでも構いません。SaaS(インターネット経由で使う業務ソフト)を、他社のクラウド基盤の上で提供する会社もあります。JIPDEC のユーザーズガイド追補は、その会社は両方の立場になると説明しています。

版には注意が要ります。ISMS-AC によると、2026 年 7 月 27 日に ISO/IEC 27017:2026 が発行されました。ISO の規格のページでは、2015 年版は廃止(Withdrawn)と表示されています。認証基準の JIP-ISMS517 は JIPDEC が改訂中で、2026 年秋ごろの発行をめどにしています。認証を持つ組織は改訂版へ移る必要があり、移行期間は改訂版の発行後 3 年の予定です。この記事の番号と名称は、いまの認証が使う 2015 年版のものです。なお、ISMS の規格 ISO/IEC 27001:2022(日本語版は現在 JIS Q 27001:2025)では、管理策が 5〜8 の 4 つの箇条に整理し直され、番号が変わっています。新しい番号でのアカウント管理は ISO/IEC 27001:2022 のアクセス制御の管理策を SaaS に当てはめるにまとめています。2026 年版の番号と中身は、公開資料では確かめられませんでした。

アカウント管理の管理策と、手引の向き先

JIP-ISMS517 の参考 A には、適用宣言書(どの管理策を使い、使わないものはなぜかを書く文書)の記入例があります。その表では、27017 に手引がない欄に「−」と「27017 には追加の実施の手引なし」が書かれています。ここから、アカウント管理の管理策ごとに、27017 の追加の手引が利用企業と事業者のどちらにあるかが読み取れます。

「なし」は、27002 の一般の手引だけが当てはまるという意味です。ID の登録と権限の付与で事業者にだけ手引があるのは、利用企業の担当者の ID を作る仕組みを事業者が用意するからだと読めます。ただし手引の中身は規格本文にあり、公開資料では確かめられません。一方で、権限の見直しと、退職や異動での削除には、クラウド特有の手引が足されていません。クラウドのサービスでも、社内のシステムと同じ一般の手引に沿って、自社の決まりで行うことになります。

パスワードの渡し方で確かめること

9.2.4 の手引は、ユーザーズガイド追補が様式の例として引用しています。利用企業には、パスワードなどを発行して渡す事業者の管理手順が、自社の求めを満たすかを確かめるよう勧めています。事業者には、発行の手順と本人を確かめる手順を含めて、管理の手順の情報を利用企業に出すよう勧めています。どちらも文末は「望ましい」で、必ず行うことではなく推奨の書き方です。

追補は、利用企業向けの手引の大半が「事業者に確かめる」形だが、確かめること自体は目的ではないと説明しています。確かめた結果どれだけ危険が残るかを評価し、足りなければ自社の対策に加える、という流れです。たとえば、サービスが担当者ごとに ID を作れないとします。1 つの ID を数人で使うしかないなら、誰が入ったかを別の方法で残す対策を自社で足すことになるでしょう。

利用の記録と、管理者の権限

追補は、附属書 A(規格の末尾にあるクラウド向けの追加の管理策)の CLD.12.4.5「クラウドサービスの監視」を挙げています。利用企業は、利用を許した人の使い方を確かめる手順を作ります。そのために、記録の種類・見方・保存期間を事業者に確かめることが望まれる、という説明です。追補は、事業者が利用企業向けに用意する管理画面では、見られる監視の項目が限られることが多いとも書いています。

管理者権限については、追補は利用企業の方針(5.1.1)で扱う事柄として、クラウドを動かす側の管理者が強い権限を持つことを挙げています。事業者の側も、自社の管理者が持つ強い権限に起因する危険への対策を、方針に書き足すよう勧められています。管理者用のアカウントの考え方は特権 ID(管理者用アカウント)とはにあります。

役割の分担を文書にする

附属書 A には CLD.6.3.1「クラウドコンピューティング環境における役割及び責任の共有及び分担」があります。追補は関連する 6.1.1 について、役割と責任の受け持ちを事業者・供給者・利用企業の間で決め、合意して文書にするよう勧めています。供給者は、事業者がサービスに使う他社のことです。JIP-ISMS517 は、クラウドの危険の最終的な責任は利用企業が持つとしています。そのうえで事業者は自分の管理範囲に責任を持ち、果たしていることを契約を含む取り決めで利用企業に示す必要がある、と書いています。

認証の審査では、適用範囲を書いた文書にクラウドサービスの名前を入れます。27017 の管理策は原則としてすべて評価し、サービスの種類によって当てはまる管理策がない場合だけ除外できます。アカウントについて用意するものの一例は、事業者なら、パスワードの発行と本人確認の手順、利用記録の種類と保存期間を説明する資料です。利用企業なら、その資料を確かめた記録と、足りない分を自社で補う手順です。