ID管理の一般的なフレームワークとセキュリティ対策をISOやNISTを参考にして整理してみた
組織がシステムやサービスを利用していれば、そこにIDはあるはずで、ID管理は必須の業務になリます。
ID管理を考える際にライフサイクルの整理とセキュリティ対策が必要ですが、広範に適用できる一般的なフレームワークがなかなか見つからず製品やベンダごとのばかり整理が目についたので、ISOやNISTで関連する部分を抽出してみました。
出来心で始めたものの、ISOやNIST大変わかりづらい割に実装方針自体は(当たり前ですが)記載されていないので、この記事も方針や基準のみをまとめており、実装の指針は乏しいです。
もう一歩検討を進めないと運用としては実現できないのがちょっとつらいところですね…。
なお本記事はblg8さんの「ID管理」についてを参考に作成しました。
特に「IDとは」「IDライフサイクル」といったテーマが大変わかりやすく整理されていたので、参考にしながら作成しました。大変助かりました。ありがとうございます。
私の記事では、blg8さんの整理のその先でどのような対策が必要になるかを重点的に書いております。
要約
- ライフサイクル自体は"ISO/IEC 24760-1:2019 IT Security and Privacy"で整理されており、各ステージとステージ間の遷移がフレームワーク化されている。
- セキュリティ対策としてのライフサイクル管理はNISTに記載がある。
- 基本的なアカウント(ID)管理の対策 : "NIST SP 800-53 AC-2 アカウント管理"
- 登録と認証の対策 ： "NIST SP 800-63"
- 具体的な実装方針は個々の組織やシステムで検討する必要があるが、準拠すべき一定の基準として参照できる。
参考資料
- IDライフサイクルの整理
- ISO/IEC 24760-1:2019 IT Security and Privacy — A framework for identity management Part 1: Terminology and concepts ISO公式の一覧ページはこちら
- blg8, 「ID管理」について
- 必要なセキュリティ対策
- NIST SP 800-53 組織と情報システムのためのセキュリティおよびプライバシー管理策 IPAによる翻訳PDFはこちら
- NIST SP 800-63 電子的認証に関するガイドライン IPAによる翻訳PDFはこちら
前提1： IDのライフサイクルとセキュリティ対策は別物
まずライフサイクルの整理に入る前に、重要な前提を整理しておきます。
IDの管理の仕組みを検討する際に自分が最初に引っかかったのは、ライフサイクルそのものと、ライフサイクル上のイベントに対するセキュリティ対策を混同して考えてしまったことです。
考えてみると当たり前ですが、下記のように違いがあります。
- IDライフサイクル：ID自体がどのように作成から削除までのイベントを迎えるか
- IDライフサイクルに関するセキュリティ対策：ライフサイクル上の各状態・イベントのセキュリティリスクへの対策
例えば、利用開始時の認証(本人確認)はライフサイクルイベントの一つですが、パスワードやMFAの設定、写真や公的資料の確認などのセキュリティ対策はライフサイクルのイベントそのものではないです。
この前提を理解すると、ISO/IEC 24760が理解しやすいです。
前提2: NISTの位置づけ
NIST SP 800-53ではアクセス管理の管理策が規定
この基準は1.1 目的及び適用性に下記のようにある通り、セキュリティ全般の管理について組織及びシステムの観点から記載したものです。
アカウント管理という観点では3.1アクセス制御 AC-1, AC-2あたりが参考になりますが、アカウントのライフサイクルという観点での整理ではないです。
むしろアカウント管理全般に対する管理策が記載されているため、あえてライフサイクル管理の対策として整理する意味は薄いですがやってみます。(意味が薄いことを理解できたのが収穫でした)
NIST SP 800-63では電子認証に関するガイドライン
この基準は電子認証を実装する愛の技術的なガイドラインです。
電子認証のモデルについて定義があり、トークンの扱いや本人確認の方法、プロトコルが抽象的に記載されています。
アカウントライフサイクルの観点では、特にアイデンティティの登録に関する記載が直接的に参照できます。
ライフサイクルの整理
まずはISO/IEC 24760 7.2 Identity lifecicleを見て、IDのライフサイクルを整理します。
Figure 1にスパゲッティのようなライフサイクルの図があるので、見やすく下記の通り整理してみます。
7.2のFigure1をよく見ると無効(Suspended)から未登録(Unknown)に線はないですが、無効化したアカウントを削除することはあり得るので付け足しております。ISO 24760の全体の趣旨には影響ないと思います。
大体は直感的に理解できると思いますが、一部違いをはっきりさせておいた方が良いものを書いておきます。
ライフサイクルのステージ
- 確立済 Established
- 登録プロセスで必要なアイデンティティ情報が検証され、参照識別子等の追加情報が生成されて、情報が登録された状態
- 有効 Active
- 管理システムにアイデンティティ情報が存在し、サービスドメイン内のリソースを利用できる状態。
ライフサイクルの遷移
アイデンティティ調整とメンテナンスは違いが分かりづらく、7.2を一読しただけではわからないです。全体を踏まえて趣旨を取ると下記のように分類できると思います。（うまく文書を読み取れているか、少し自信がないです。)
- アイデンティティ調整 Identity Adjustment
- 利用者等のIDの主体の有効化(Activation)に関わる情報が変更された場合に、IDレジスタ(IDの登録先)の情報を変更するプロセス。
- 例： ユーザーの所属や氏名の変更など、サービスドメイン内のリソースの利用可否などに影響がある変更。
- 例：認証情報の変更など、アイデンティティを担保する情報の更新が必要な場合。
- メンテナンス
- アイデンティティ情報の正確性と整合性を維持するプロセス。
- 一般的な情報の更新や属性値の変更など、広範囲の更新を含む。
- 例： ユーザーの住所の変更など。ただし修正内容やサービスの内容によっては住所の変更がアイデンティティ調整に該当する場合もある。国を跨ぐ修正などはサービスの利用可否にも影響する場合があるので、その場合はアイデンティティ調整にも該当する。
IDライフサイクルを踏まえたセキュリティ対策
IDのライフサイクル自体の整理はISO/IEC 24760で十分ですが、この基準では必要なセキュリティ対策については記載がありません。
ここからはNIST SP 800-53/63を参考に必要なセキュリティ対策をざっくり整理してみます。
ライフサイクル管理全般のセキュリティ対策
まずライフサイクル管理全般に関しては下記のような必要な対策があります。これらはライフサイクルだけにとどまらない内容ですが、前提として必要な対策となります。
- ID管理の規定 : 組織のIDのライフサイクルに関する規定
- 監視と通知 : IDの利用状況の監視と管理者への通知
- 監査プロセス : 利用状況の監査と、規定や管理要件への準拠のレビュー
NIST SP 800-53 AC-2の関連記載
- システム内での使用が許可されているアカウント、および特別に禁止されているアカウントのタイプを規定し、文書化する。(管理策a)
- [組織が定めるポリシー、手順、前提条件、および基準］に従って、アカウントを作成、有効化、変更、無効化、および削除する。(管理策c)
- アカウントの使用を監視する。(管理策j)
- ［組織が定める頻度］でアカウントのアカウント管理要件への準拠をレビューする。(管理策j)
- アカウントの作成、変更、有効化、無効化、および削除措置を自動的に監査する。(拡張管理策(4))
ステージ間の遷移に関するセキュリティ対策
ID管理全般のセキュリティ対策を考える場合は、ライフサイクルのみならずデータの管理や認証(ログイン)方法、権限設計など、広範な範囲を考える必要があります。
一方でライフサイクルを管理することを考えると、ステージ間の遷移に着目して整理が可能で下記のような観点が存在します。
- ステージ間の遷移の方法が妥当か
- ステージ間を遷移すべきIDが適切に抽出されているか
- ステージ感を遷移すべきタイミングで適切に遷移できているか
例えば、「登録 Enrolment」の遷移では、適切な本人確認や認証プロトコルが必要です。
一方でID管理全般の観点で考えると、例えばクレデンシャルの適切な保護や、有効(Active)なIDを使って適切にログインする方法の検討が必要となります。
今回はIDのライフサイクル管理に着目してセキュリティ対策を考えるため、主要なステージ間の遷移について必要な対策を洗い出してみます
登録 Enrollment
NIST SP 800-63の記載
- 登録と身元識別情報の検証(7章)
対応が必要なリスクとして主になりすましに対しての対策が記載れており、本人確認の方法がレベル別に整理されています。
かなり細かいので、詳細は直接「7.2 登録のレベル」を参照して欲しいですが、本人確認書類の番号申請から対面での確認までいろいろな手段が記載されています。
NIST SP 800-53 AC-2の関連記載
- システム内での使用が許可されているアカウント、および特別に禁止されているアカウントのタイプを規定し、文書化する。(管理策a)
- グループと役割の資格には［組織が定める前提条件と基準］を必要とする。(管理策c)
- アカウントの作成要求には［設定：組織が定める職員または役割］による承認を必要とする。(管理策e)
要するにルールを作り、基準に基づいて承認されたアイデンティティのみを登録するという管理策です。
承認の部分が引っかかる方がいらっしゃると思いますが、NISTはアメリカ政府のシステムを念頭に作られているものなので、背景を踏まえると「承認」というアクションが基準に入ることは自然に理解できるかと思います。
有効化 Activation
有効化とはサービスドメインの中でリソースにアクセスできる状態にすることを指します。なるほど権限を付与するのか、と考えましたが少し違うようです。
よく読むと「権限を付与する」という意味合いより、アクセスを可能にするために「アイデンティティ情報をIDに付与する」という意味が強いです。
例えば、ある社員が監査の担当部署に異動となったので、「当該社員が監査担当部署の一員であるという情報を付与する」ことで監査のに必要なリソースアクセスできるよう有効化するという考え方です。
IDを起点に整理しようとすると、確かに上記の理解の方がしっくりきます。
NIST SP 800-53 AC-2の関連記載
- 以下に基づいて、システムへのアクセスを認可する。(管理策i)
- 有効なアクセス認可。
- 意図されたシステムの利用。
- ［設定：組織が定める属性（必要に応じて）］。
アイデンティティ調整 Identity Adjustment
アイデンティティ調整は有効化に関連するアイデンティティの情報が変更された場合に、正しく属性を更新することを指します。
権限制御においては要の概念の一つですが、アイデンティティ情報(所属等)はシステムの側からは見えないことが多いため、実はテクノロジーで解決し辛い部分でもあると思います。
逆に、組織の取り組みとして適切に情報を反映させる仕組みが必要となるため、運用が正常に回るような支援の仕組みなどが必要な領域です。
NISTの記載はルールを定めているに近い内容なので、各システム・組織で実装から考える必要があります。
NIST SP 800-53 AC-2の関連記載
- アカウント管理者および［設定：組織が定める職員または役割］に以下の期間内に通知する。(管理策h)
- アカウントが不要になった場合［設定：組織が定める期間］。
- ユーザが退職または異動となった場合［設定：組織が定める期間］。
- 個人のシステムの利用権限または知る必要性を変更する場合［設定：組織が定める期間］。
- アカウント管理プロセスを、職員の退職および異動プロセスと連携させる。(管理策l)
一時停止・再有効化 Suspenssion / Reactivation
IDの一時停止と再有効化もセキュリティ上は重要な機能の一部です。アタックサーフェスを減らす予防効果と、実際にセキュリティ侵犯の疑いがあるアカウントの凍結といった止血措置を行います。
NIST SP 800-53 AC-2の関連記載
- アカウントが次の場合は、［設定：組織が定める期間］内にアカウントを無効化する。(拡張管理策(3))
- 失効している。
- すでにユーザーまたは個人に関連付けられていない。
- 組織のポリシーに違反している。
- 組織が定める期間にわたって非アクティブであった
- ［組織が定める重大なリスク］を発見した場合、［組織が定める期間］内に個人のアカウントを無効にする。(拡張管理策(13))
まとめとNext action
IDライフサイクルの一般的なフレームワークと、必要なセキュリティ対策は整理できました。
あとは実装だ・・・というわけですが、実装は実装でいろいろな方法が考えられます。また組織・システムの特性によって優先順位も大きく異なります。
実装面での検討に進む方はAWSのIAMでのセキュリティのベストプラクティスあたりを読むとイメージが掴めると思います。