【SCS評価制度】退職者のアカウントは消えていますか？—アイデンティティ管理という『入口』の守り方
- 2 日前
- 読了時間: 11分
更新日：2 日前
SCS評価制度の大分類4「攻撃等の防御」/ 中分類4-1「アイデンティティ管理、認証、アクセス制御」
「アイデンティティ管理」で本質的に求められるものとは
SCS評価制度の中分類4-1「アイデンティティ管理、認証、アクセス制御」は、★3の81評価基準のうち、1/3にあたる27評価基準を占め、最重要パートと言っても過言ではありません。
ここで本質的に求められているのは、単に多要素認証やパスワードポリシーといった個々の機能を導入することではありません。
重要なのは、「誰が」「どの資産に」「どのレベルの権限で」アクセスできる状態にあるのかを、発行から削除まで一連の手続きとして管理し続けることです。
はじめに
「資産の可視化」では、SCS評価制度が大分類3で「何を守るべきか」を明確にすることを求めている、というお話をしました。資産の全体像が見えて初めて、次に問われるのが「その資産に、誰がアクセスできる状態になっているか」という問いです。これが、大分類4-1「アイデンティティ管理、認証、アクセス制御」の領域になります。
セキュリティのご支援の現場でよく目にするのが、
退職者のクラウドサービスへのアクセス権限が残ったままになっている
異動によって不要になったはずの権限が、削除されずに引き継がれている
管理者IDを複数人で共有しており、誰が何を操作したのか特定できない
といった課題が見つかるケースが多くあります。境界防御（ファイアウォールやウイルス対策）は「外から入られないための対策」ですが、これらの課題はいずれも、すでに正規に発行された「内側の鍵」の管理不全によって生じるものです。侵入の起点は、外壁の穴よりも、開けたままの内扉であることの方が、実務では圧倒的に多いのです。
アイデンティティ管理の不備が招いたインシデント
事例①：ベネッセ—「業務上必要な範囲」を超えたアクセス権限
2014年に発覚したベネッセの個人情報流出事件では、約2,900万件の顧客情報が外部に流出しました。顧客データベースの運用・保守を委託されていた企業からさらに再委託を受けていた派遣社員が、業務上顧客情報にアクセスできる権限を持っていたことを悪用し、情報を持ち出して名簿業者に売却したことが原因でした。私物のスマートフォンへのデータ転送を止める制限もなく、結果として補償原資だけで200億円規模の対応が必要になりました。
出典： ベネッセコーポレーション「お客様本部からのお知らせ（個人情報漏えいに関するご報告）」
事例②：NTT西日本子会社—10年間気づかれなかった管理者権限の悪用
2023年に発覚したNTT西日本子会社の情報流出事件では、約900万件の顧客情報が流出しました。コールセンターシステムの保守を担っていた元派遣社員が、システム管理者権限を悪用し、約10年間にわたって顧客データをダウンロードし、外部の名簿業者へ売却などをしていたことが判明しています。
出典： NTT西日本「お客さま情報の不正流出に関するお詫びとお知らせ（2024年1月26日公表）」
事例③：LINEヤフー—委託先を経由した認証基盤への不正アクセス
2023年11月に公表されたLINEヤフーの不正アクセス事案では、最大約44万件の情報が流出しました。LINEヤフーと韓国NAVER Cloudの両社から委託を受けている企業の従業員のPCがマルウェアに感染し、両社の従業員情報を扱う共通の認証基盤への接続が許可されていたことから、そこを経由して不正アクセスが行われました。再発防止策として、同社は従業員向けシステムへの二要素認証を標準とする方針を新たに打ち出しており、裏を返せば、それまで認証基盤の一部が多要素認証で保護されていなかったことがうかがえます。
出典： LINEヤフー株式会社「不正アクセスによる情報漏えいに関するお知らせ」
これら3つの事例に共通するのは、いずれも高度な技術的欠陥ではなく、「ID・アクセス権限の運用が徹底されていなかった」という管理不備が引き金になっている点です。必要以上に広く与えられたアクセス権限、長期間点検されなかった管理者ID、委託先を含めた認証基盤の甘さ――これらはどれも、SCS評価制度の大分類4-1「アイデンティティ管理、認証、アクセス制御」が具体的な要求事項として定めている内容そのものです。
ID管理は防御の「入口」
防御・検知・対応・復旧といった後続の対策は、突き詰めれば「誰が正規の利用者で、誰がそうでないか」を区別できることを前提に成り立っています。この前提が崩れていると、どれだけ高度な監視ツールを導入しても、正規のIDを使った侵入者を「異常」として検知することができません。
近年広く語られる「ゼロトラスト」という考え方も、根本にあるのはこの発想です。米国NISTが整理するゼロトラストアーキテクチャの考え方では、一度認証されたユーザーや機器を無条件に信用し続けるのではなく、アクセスのたびに継続的に検証することが求められます。SCS評価制度の4-1が、IDの「発行」だけでなく「削除」や「棚卸」までを要求しているのも、“信用を固定化させない”という考え方と同じものと考えられます。
4-1-1・4-1-2：IDは「発行」ではなく「手続き」として管理する
4-1-1（ユーザIDの管理手続）と4-1-2（管理者IDの管理手続）では、IDの発行・変更・削除を、その場しのぎの対応ではなく、申請・承認を伴う一連の手続きとして運用することが求められます。
特に管理者ID（4-1-2）については、要求される内容がより細かくなります。サーバやネットワーク機器ごとに管理者・責任者を定めること、開発担当者が本番環境で管理者権限を使えないようにすること、そして誰が管理者IDを保有しているかを組織として把握できる仕組みを持つことなどが含まれます。
実務でよく見られるのは、「退職者が出たタイミングでまとめて棚卸しをする」という運用です。しかしこれでは、退職から棚卸しまでの期間、権限が生きたまま放置されることになります。4-1が求めているのは、こうした事後対応ではなく、IDが不要になった時点で速やかに削除・無効化される仕組みです。
4-1-3：認証の強度は、機密区分に応じて変える
以前の記事で、SCS評価制度が求める情報管理は「機密区分（3-1-4）に応じて取扱いルールを変える」という考え方に基づいていると解説しました。この考え方は、認証の設計にもそのまま当てはまります。
4-1-3（認証の強度・実装方法の決定）では、★3の段階で、重要な情報を扱うクラウドサービスへのアクセスに多要素認証を用いることが求められます。そして★4になると、対象範囲がさらに広がり、管理者がインターネット経由でシステムにアクセスする場合や、機密区分が高い情報を扱うシステムに社内外からアクセスする場合にも、多要素認証が必須になります。
つまり、「全システムに一律で同じ認証を課す」のではなく、「機密区分の高い情報・システムほど、認証も厳格にする」という、資産可視化編で述べた重要度に応じた管理の考え方が、認証設計にもそのまま貫かれているのです。
このほか、4-1-4（アカウントロック制御）、4-1-5（パスワード設定ルール）、4-1-6（パスワード管理ルール)では、初期パスワードの変更、推測されやすい単語の使用禁止、パスワードの使い回し禁止など、基本的でありながら見落とされがちなルールが具体的に定められています。「デフォルトパスワードを変更する」という項目は、ネットワーク機器や新規契約したクラウドサービスの初期設定でしばしば見落とされる典型的な穴です。特に外部事業者に委託している場合は注意が必要です。
4-1-7〜4-1-9：アクセス権そして物理・可搬媒体まで
4-1-7では、★3の段階で、アクセス権の発行・変更・削除を申請・承認のもとで管理し、業務上必要な範囲に限定して付与することが求められます。さらに★4では、年1回以上のアクセス権棚卸しの実施に加え、重要情報を扱うシステムでは利用者権限と管理者権限を分離し、特定の個人に権限が集中しない運用が求められます。
ここで重要なのは、「役職」ではなく「業務」で権限を考えることです。例えば、社長だからという理由だけで管理者権限を付与するのではなく、実際の業務に必要な権限だけを割り当てることが基本となります。経営層のアカウントは社内外との接点も多く、標的型攻撃やフィッシングの対象になりやすいため、万が一アカウントが侵害された場合の影響は非常に大きくなります。だからこそ、最小権限の原則を徹底することが重要です。
また、現場では「管理者アカウントを複数人で共用している」というケースも少なくありません。しかし、特権IDは一般ユーザーIDよりも権限が強く、不正利用や情報漏えいが発生した際の影響範囲が大きくなります。さらに、共用アカウントでは「誰が、いつ、何を実施したのか」を追跡できず、監査やインシデント対応も困難になります。そのため、特権IDは個人単位で払い出し、必要な場合のみ利用する運用が望まれます。
さらに、SCS評価制度ではアクセス権をシステム上のIDだけに限定していません。4-1-8（サーバ設置エリアへの入退室管理）では、サーバルームなど重要設備への入退室を適切に管理し、記録を残すことが求められます。また、4-1-9（可搬媒体の制限）では、USBメモリや外付けHDD、スマートフォンなどの可搬媒体について、持込み・持出しや利用ルールを定め、必要に応じて利用を制限することが求められます。
つまり、SCS評価制度が考えるアクセス管理とは、「システムにログインできるか」だけではありません。「誰が情報にアクセスできるのか」「誰がサーバルームに入れるのか」「誰がデータを外部へ持ち出せるのか」まで含めて、一貫したアクセスコントロールを構築することが目的です。デジタルと物理の両面から情報資産を守ることが、SCS評価制度の考え方といえるでしょう。
「手形」は発行して終わりではない
ここまで見てきた4-1の要求事項に共通しているのは、「IDや権限を発行すること」ではなく、「発行後も継続的に管理し続けること」に重点が置かれている点です。退職や異動、組織変更、契約終了など、人や組織の状況は日々変化します。そのたびに、不要になったアカウントは削除されているか、権限は業務内容に応じて適切に変更されているかを確認し続けることが求められます。
これは、前回の記事でご紹介した「資産台帳は作って終わりではない」という考え方と本質的には同じです。資産台帳が継続的な棚卸しによって最新の状態を維持する必要があるように、IDやアクセス権も、発行した瞬間から陳腐化が始まります。異動した社員に以前の部署の権限が残っていたり、退職者のアカウントが有効なまま残っていたりする状態は、情報漏えいや不正アクセスのリスクを高める要因となります。
SCS評価制度で求められる年1回以上のアクセス権棚卸しは、単なる監査のための作業ではありません。人や組織の変化によって生じる「権限のずれ」を定期的に是正し、最小権限の原則を維持するための仕組みです。
つまり、4-1が目指しているのは、「IDを発行する運用」ではなく、「IDと権限をライフサイクル全体で管理する運用」の実現です。IDは一度発行したら終わりではなく、発行・変更・棚卸し・削除までを一連のプロセスとして継続的に運用することで、初めて適切なアクセス管理が実現できるのです。
おわりに
私たちがSCS評価制度への対応をご支援する中で、「多要素認証を導入したから安心」「パスワードポリシーを厳格にしたから十分」というお声をよくお聞きします。
確かに、多要素認証や強固なパスワードは、不正ログインを防ぐうえで非常に重要な対策です。しかし、それだけでは「誰がどの権限を持ち、現在もその権限が適切なのか」という問いには答えられません。退職者のアカウントが残っていないか、異動した社員に不要な権限が付与されたままになっていないか、管理者権限が適切に分離されているかといった運用まで含めて初めて、アイデンティティ管理が機能していると言えます。
SCS評価制度が評価しているのは、個々のセキュリティ製品や機能ではなく、それらを継続的に運用できる組織の仕組みです。そのため、認証機能を導入することがゴールではなく、人や組織の変化に合わせてIDやアクセス権を維持・管理し続ける体制を構築することが重要になります。
次回は、大分類4-2以降で扱う「ネットワーク」「デバイス」「サーバ」「バックアップ」など、システムを守るための技術的対策について解説します。アイデンティティという「誰が利用するか」の管理から、システムそのものを「どのように守るか」へと視点を広げながら、SCS評価制度が目指す多層的なセキュリティ対策を見ていきます。
弊社では、SCS評価制度への対応を単なる評価取得ではなく、企業ごとの事業やリスクの実態に即した情報セキュリティ基盤を構築する機会と考えています。
多要素認証やパスワードポリシーといった技術的な対策は重要ですが、それだけでは十分ではありません。誰にどの権限を付与するのか、異動や退職に合わせて権限を適切に見直せているのか、特権IDを適切に管理できているのかといった運用まで含めて初めて、実効性のあるアイデンティティ管理が実現します。
SCS評価制度への対応をきっかけに、「認証の強化」だけではなく、「誰が、何に、どの権限でアクセスできるのか」を継続的に管理できる仕組みを整え、事業を支える情報セキュリティ基盤の構築につなげていただければ幸いです。
