前回の記事では、「サプライチェーン強化に向けたセキュリティ対策評価制度(以下、SCS評価制度)」が推進される背景や全体設計の考え方をご紹介しました。今回の記事では、★3・★4の要求事項に対してOktaが考えるアプローチをご紹介します。
SCS評価制度対応を仕組み化する重要性
SCS評価制度の要求事項は、特定のセキュリティ製品を導入するだけでクリアできる性質のものではありません。技術的なアクセス制御から物理的な入退室管理、さらには社内規程の策定や従業員教育にいたるまで、求められる領域が非常に多岐にわたります。
手動運用の限界
多くの組織では、IDの発行・変更・削除といった管理業務が、依然としてワークフローシステムからの手作業による転記や、表計算ソフトを使ったマニュアル管理で行われています。しかし、こうした手動運用は以下のようなセキュリティリスクを抱えます。
従業員の退職や契約終了時に手作業での削除漏れが起きると、組織の管理が届かない「幽霊アカウント」が残ってしまいます(評価基準 4-1-1-3対応)。これが不正アクセスの侵入経路となるリスクがあります。
部署異動や職務変更があった際、過去に付与された特権が削除されずにそのまま残るケースもあります(評価基準 4-1-1-4対応)。権限が累積していくことで、本来徹底すべき「最小権限の原則」が形骸化してしまいます。
手動による台帳更新では、いつ誰が操作したのかという正確なログが残りにくいため、外部監査の場で「その時点で本当に適切な権限だったか」を証明することが難しくなります(評価基準 4-4-3-1対応)。
評価の継続的な運用と現場の負担軽減
SCS評価制度は、一度★を取得すれば終わりではありません。多くの項目において年1回以上の頻度での点検・棚卸が明示的に義務付けられています。
たとえば、★4で必須となる「付与したアクセス権の棚卸(評価基準 4-1-7-2)」を作業者が手動で行う場合、各種SaaSや社内システムからアカウントリストを書き出し、人事データと突き合わせ、各部門長にメールやチャットで確認を求め、回収した結果をもとにまた手作業で権限を書き換える……といった膨大な作業が毎年発生します。
だからこそ、セキュリティとガバナンスを維持する仕組みが必要不可欠です。上述のアイデンティティ管理に関連する運用を仕組み化することができれば、SCS評価制度における指摘リスクを減らせるだけではありません。自動化によって捻出された時間は、システムによる代替ができない社内規程の整備や取引先との契約見直し、インシデント対応体制の構築といった他の作業のために再配分することが可能となります。
Oktaが関連する評価基準
正式にはセキュリティ専門家・評価機関が判断することになりますが、当社の従業員向けアイデンティティ管理ソリューションである「Okta Workforce Identity」は、SCS評価制度の多くの要求事項に対して、中心的な対策を主導したり、他製品との連携による補完的対策を提供できると考えています。
Okta製品が対策の中心となり得る評価基準
Okta Workforce Identityが中心となって貢献し得る評価基準を一部リストアップしました。
※ 評価基準の項目は「サプライチェーン強化に向けたセキュリティ対策評価制度(SCS評価制度)> 要求事項・評価基準」に掲載のExcelより引用しています。
No(★) | 評価基準 |
4-1-1-1(★3) | ・自社の役員、従業員、派遣社員及び受入出向者に対するユーザIDの付与・変更・削除は申請・承認制にすること。 |
4-1-1-2(★3) | ・ユーザIDの共有について、以下のいずれかを適用すること。 ・ユーザIDを共有しない。 ・やむを得ず共有IDが必要な場合(例えば、システムの仕様により、使用人数分のユーザIDを発行することができない場合)は、共有IDを利用したユーザを特定できるようにする。 |
4-1-1-3(★3) | ・ユーザIDが不要になった場合(例えば、ユーザが組織を退職した場合又はユーザIDが一定期間使用されなかった場合)、速やかにユーザIDを削除又は無効化すること。 |
4-1-1-4(★3) | ・ユーザIDに付与したアクセス権が不要になった場合(例えば、ユーザの業務上の役割が変わった場合)は、当該権限を速やかに削除又は無効化すること。 |
4-1-2-2(★3) | ・管理者権限を付与する役員、従業員、派遣社員及び受入出向者を限定したうえで、管理者IDについて以下のいずれかを適用すること。 ・管理者IDを共有しない。 ・やむを得ず管理者IDの共有が必要な場合(例えば、システムの仕様により、使用人数分のIDを発行することができない場合)は、共有の管理者IDを利用したユーザを特定できるようにすること。 |
4-1-2-3(★3) | ・各管理者IDに対して当該IDの用途に応じた必要最低限の権限のみを付与すること。 |
4-1-2-5(★3) | ・組織内でどの役員、従業員、派遣社員及び受入出向者が管理者IDを持っているかを把握するための仕組みを整備すること。 |
4-1-2-6(★3) | ・管理者IDが不要になった場合(例えば、管理者が組織を退職した場合及び管理者IDが一定期間使用されなかった場合)、速やかに管理者IDを削除又は無効化すること。 |
4-1-2-7(★3) | ・管理者IDの付与・変更・削除は申請・承認制にすること。 |
4-1-2-8(★3) | ・管理者IDの付与・変更・削除並びにサーバ及びネットワーク機器の設定内容の変更を行う権限を業務上必要な役員、従業員、派遣社員及び受入出向者に限定すること。 |
4-1-3-1(★3) | ・すべてのユーザID及び管理者IDについて、システム及び情報機器へのアクセスを許可する前に、ユーザIDごとに設定されている認証情報(パスワード等)でユーザを認証すること。 |
4-1-3-2(★3) | ・重要な機密情報を取り扱うクラウドサービスにおいて、ユーザ及び管理者がサービスにアクセスする場合は、常にNo.4-1-3-3で示す認証要素を利用した多要素認証を使用すること。 |
4-1-3-3(★3) | ・多要素認証の使用に当たっては、以下のいずれかの要素から2種類以上を選択し、利用すること。 ・知識情報(例：ID・パスワード) ・所有情報(例：ワンタイムパスワード※又は証明書) ・生体情報(例：指紋、顔、虹彩又は静脈) ・その他の情報(例：IPアドレス) ※利用者のメールアドレス、電話番号等に対してワンタイムパスワードを送信して利用者に入力させる方法及びスマートフォンへの認証要求を利用した認証方式を含む。 |
4-1-3-4(★3) | ・多要素認証の知識情報として用いるパスワードは、8文字以上とすること。 |
4-1-3-5(★4) | ・重要な機密情報を取り扱うシステムにおいて、No.4-1-3-2で対象としているクラウドサービスへのアクセスに加えて、以下に示す場合は、常にNo.4-1-3-3で示す認証要素を使用した多要素認証を使用すること。 ・インターネットを経由して社内環境へ接続する場合 ・管理者がインターネット経由でシステムにアクセスする場合 ・ユーザがインターネット経由で重要な機密情報を取り扱うシステムにアクセスする場合 |
4-1-5-2(★3) | ・ユーザ認証にパスワードを利用する場合、推測されやすい単語の設定を禁止するよう社内ルールを定めること。 |
4-1-5-3(★3) | ・ユーザ認証にパスワードを利用する場合、以下のいずれかの保護対策を講じるよう社内ルールを定めること。 ・No.4-1-3-3で示す認証要素を利用した多要素認証を使用するか、又は試行が少なくとも10回失敗した場合にアカウントロックするように制限したうえで、パスワードの長さを8文字以上とする。 ・上記のとおり多要素認証又は試行回数の制限を実施できない場合、パスワードの長さは、英大文字小文字、数字を含めた10文字以上とする。 |
4-1-6-2(★3) | ・パスワードの漏洩が判明した場合、又はその疑いがある場合に速やかにパスワードを変更するための手順を定めること。 |
4-1-7-1(★3) | ・業務で利用するシステム及びパソコンへのログオン時のユーザのアクセス権並びに機密上の配慮が必要な場所及び部屋への入室について、以下の内容の管理ルールを定めること。 ・アクセス権の発行・変更・削除は申請・承認制であること。 ・与える入室許可・アクセス権の範囲は必要な範囲に限定すること。 ・入室権限及びアクセス権の棚卸について定めていること。 ・与えた入室許可・アクセス権の申請書又は台帳を管理していること。 |
4-1-7-2(★4) | ・年１回以上の頻度で役員、従業員、派遣社員及び受入出向者に付与したアクセス権の棚卸を実施すること。 |
4-1-7-3(★4) | ・重要な機密情報を扱うシステムは、アクセス権を付与するための条件を定めること。 |
4-1-7-5(★4) | ・重要な機密情報を扱うシステムは、ユーザ及び管理者ごとに必要最小限の権限を付与し、個人に権限が集中しない環境とすること。 |
4-4-3-2(★4) | ・No.4-4-3-1で取得及び保管を求めるログを脅威から保護するため、ログを保存する媒体及びシステムにインターネット経由でアクセスする場合は、常にNo.4-1-3-3で示す要素を利用した多要素認証を使用すること。 |
4-4-3-3(★4) | ・No.4-4-3-1で取得及び保管を求めるログのうち、認証サーバのログについては、月1回以上の頻度でモニタリングを実施し、不審な認証試行を検知すること。 |
Okta製品が他製品や運用との組合せで補完し得る評価基準
エンドポイント管理(EDR/MDM)、ネットワーク境界防御(SASE)、ログ分析管理(SIEM)など、他製品が対策の中心となる領域であっても、Oktaがデバイスのリスクシグナル受信による認可判断、SAML/OIDCやSCIMによる認証・属性情報の同期、SIEMへのシステムログ転送といった連携を行うことで、補完的にセキュリティを強化し、運用を効率化できる評価基準があります。その一部を以下にリストアップしました。
No(★) | 評価基準 |
1-2-2-2(★4) | ・入手した情報又はログの相関分析等により、サイバー攻撃の予兆及びインシデントの発生の検知を可能とし、インシデントの防止及びインシデントが発生した場合の対応が導き出せる体制を整備すること。 |
1-3-1-2(★3) | ・定常的に役員、従業員、派遣社員及び受入出向者が最新のセキュリティ対応方針を参照できるようにすること。 |
1-4-1-1(★4) | ・セキュリティ担当部署は、年１回以上、セキュリティを統括する役員(例えば、CISOを設置する会社の場合は、当該CISO)に対して、以下にて求める対策の点検の結果を踏まえたセキュリティ対策の実態及び当該実態を踏まえて策定した今後の対策推進計画を報告し承認を得た上で、当該報告結果を社内部署と共有すること。 |
4-1-4-1(★3) | ・パソコンへのログオン及びスマートデバイスのロック解除にあたって、以下のいずれかを適用すること。 ・試行回数を調整し、試行が失敗するたびに試行間隔が長くなるようにする。 ・試行が少なくとも10回以上失敗すると端末をロックする。 ・上記で示す要件のいずれも設定することができない場合、No.4-1-5で求められるよりも強度の高いパスワードを用いる等の代替策を用いること。 |
4-1-4-2(★3) | ・パソコンへのログオン及びスマートデバイスのロック解除を行う場合、最低でも6文字以上のパスワード又はPINを利用すること。 |
4-1-7-6(★4) | ・重要な機密情報を扱うシステムは、付与したアクセス権の運用/利用状況を監視する仕組みを整備すること。 |
4-4-1-3(★3) | ・サーバ及びネットワーク機器の設定変更を申請・承認制にすること。 |
4-4-5-1(★3) | ・ネットワークに接続しているすべてのパソコン及びサーバに、マルウェア対策ソフトウェアを導入すること。 |
4-4-5-4(★4) | ・パソコン/Web ゲートウェイを対象に、不正な Web サイトへのアクセスを制限すること。 |
4-5-1-3(★3) | ・ファイアウォール(又はファイアウォール機能を持つネットワーク機器)及びルータに係る認証は、No.4-1-5で定めるパスワード設定等に関する評価基準を満たすこと。 |
4-5-1-7(★3) | ・ファイアウォール・ルールの変更をインターネット経由で行う場合、No.4-1-3-3で示す認証要素を利用した多要素認証を適用するか、又は信頼できるIPアドレスにアクセスを制限すること。 |
4-5-1-9(★4) | ・社外公開サーバ及び重要な機密情報を扱うサーバについて、それぞれ専用のネットワークセグメントに設置し、セグメント内外のアクセスを必要最小限に限定すること。 |
5-1-1-1(★3) | ・社内外ネットワークの境界又は端末において、インターネットから社内への通信及び社内から不正なサーバへの通信の双方について、不正アクセスをリアルタイム検知・遮断する仕組みを導入すること。 |
5-1-1-2(★3) | ・ネットワーク機器のログ及びアラートを分析し、セキュリティ担当部署の担当者又は管理者により不審な事象が発見された場合に、それがセキュリティインシデントに該当するかが判断されること。 |
5-1-1-3(★3) | ・No.5-1-1-1で設置したネットワーク機器又はサービスについて、以下の要件を満たす異常時に通知する仕組みを導入すること。 ・アラートが速やかに発報されること。 ・インシデントの速報レポートが作成され、通知されること。 |
また、上記以外の多くの項目でもOkta Workforce Identityは深く関与します。「仕組みの整備」や「ルールの策定」を求める評価基準にも、情報共有システムのアクセス管理や、「誰が規約を確認・同意したか」といったアイデンティティに紐づくステータス管理やガバナンスの仕組みが重要な役割を果たします。
Okta Workforce IdentityによるSCS評価制度アプローチ例
ここからはSCS評価制度の要求事項に対して、どのようにOkta Workforce Identityがアプローチできるのかその一部を具体例で紹介します。
1. 強固な認証・認可とデバイスアクセスの統合(★3要件)
すべてのセキュリティの基盤となるのが、正当なユーザーが安全な環境からアクセスしているかを正しく識別・認可する仕組みです。特にSCS評価制度では、単なるアプリケーションのログイン管理にとどまらず、端末そのものへのアクセスから統制することが求められます。
Okta Workforce Identityは、一般的なシングルサインオンや多要素認証にとどまらず、アクセス元のコンテキスト(位置情報、IPアドレス、行動パターン、デバイスの健全性、EDRからのリスクスコアなど)をリアルタイムに分析するAdaptive MFAを提供します。安全な環境からのアクセスはスムーズに許可し、不審な挙動に対しては追加認証を要求する柔軟な制御も可能です。
さらにOkta Device Accessを活用することで、WindowsやmacOSといったOSの認証を、Okta Workforce Identityのアカウントと統合できます。OSのローカルアカウントとのパスワード同期や、ログイン時における多要素認証の要求が可能になるため、ユーザーが端末を起動した直後から強固なセキュリティを確立できます。
2. IDライフサイクルの自動化(★3要件)
SCS評価制度では、従業員の退職時のアカウント削除漏れや、異動時の適切な権限変更が問われます。これらを手作業で行うことは、セキュリティリスクと運用負荷の両面で限界があります。
Okta Workforce Identityは、多様な人事システムと深く統合しながら、SaaSアカウントの自動作成と適切なライセンスの付与まで、IDのライフサイクル管理を自動化します。
ユーザーは入社初日から必要なアプリにすぐアクセスできるだけでなく、退職時に人事システム上のステータスを更新すれば、Oktaで割り当てしているアプリケーションへのアクセス権を無効化します。また、プロビジョニングに対応しているSaaSアカウントの停止を自動化し、無駄なライセンスコストの消費を防ぎます。
3. アクセス権の棚卸しと監査レポート(★4要件)
★4の要件では高度な証跡管理と厳格なガバナンス体制が求められます。特に「誰が、どのリソースに、どのような理由でアクセス権を持っているか」を継続的に証明する必要があります。
Okta Identity Governanceを利用すれば、アクセス権棚卸しのプロセスを自動化・効率化できます。
さらに、レポート機能により「誰が・いつ・どのリソースへ申請し承認されたか」のログが常に記録されるため、外部監査の際にも要求された証跡を提示できる状態を維持できます。
4. パートナー・委託先とのセキュアな連携(★4要件)
取引先のユーザーを自社の本番環境へ直接アクセスさせることは非常に危険です。
Okta Workforce Identityは、求める分離レベルのバランスに応じて、グループ会社や取引先との多様なID統合モデルを提供しています。
Realm: 単一のOkta組織内でユーザーを論理的に分割し、カスタム管理者ロールと組み合わせることで、テナントを分けることなく独立した管理境界を構築する機能。
ハブ＆スポークモデル: 親会社(ハブ)と組織ごとに独立した環境(スポーク)を連携させ、独自のガバナンスを維持する構成。
Okta Secure Partner Access:Realmに加えて、 取引先専用のOkta管理ポータルを提供する機能。
これらの仕組みにより、取引先に無理なセキュリティ投資を強いることなく、発注元がコントロールする安全なアクセス方法を提供することが可能です。
5. 高度なサイバー対策「★5」を見据えて
現在整備が進められている★3・★4の評価基準への対応はもちろんですが、将来的に求められる「★5(高度な攻撃への対応・管理)」を見据えて、拡張性のあるシステムを構築することも重要です。 たとえば、今後、企業における最大の論点のひとつとなるのが「AIエージェント(非人間アイデンティティ)に対するガバナンス」です。
将来、数多くのAIエージェントが従業員の代わりに社内システムへ膨大な回数のアクセスを行うようになります。これらのAIエージェントに対するアクセス権限の管理や監査証跡等がなければ、あらゆるアクセスが潜在的な侵害ポイントになり得ます。 Oktaは、こうしたAIエージェントなどの非人間アイデンティティにも対応するための機能開発を含む、新技術への投資を積極的に行っています。
最後に
現在の運用やシステム構成に合わせた要件定義も欠かせません。「既存の人事システムとどう連携できるか」「現状の課題に合わせて、Okta Workforce IdentityのどのSKUを選ぶべきか」といった具体的なシミュレーションや、より詳細な対策の検討を進める際は、ぜひOktaにご相談ください。貴社の環境に応じた最適なアプローチをご提案いたします。
