退職者のアカウントが、まだどこかで動いている

「辞めた人のアカウント、全部止めたっけ?」。入退社のたびに、情シスの担当者が各システムの管理画面を一つずつ開いて回る。SaaSが増えるほど、この確認は終わらなくなります。

パスワードも同じ構図です。システムごとに別のIDと別のパスワード。覚えきれない社員は使い回し、忘れた社員はリセットの依頼を出す。フィッシングで盗まれた一組が、そのまま複数のシステムの鍵になります。IDが散らばっているかぎり、守るべき入口も散らばったままです。

私たちが作るのは、ログインの入口を一つにまとめ、誰がどのシステムを使えるかを一か所で決められる状態。入口が一つなら、止めるのも一か所で済みます。ネットワークの内側を無条件に信頼しないゼロトラストの考え方でも、判断の起点は「いま入ろうとしているのは誰か」の確認です。

散らばったIDを一つの入口に
IdPを中心に業務システムをつなぐ

IDaaSを入れて終わり、にしない連携設計

Microsoft Entra ID(旧Azure AD)、Okta、Keycloak。IDaaSや認証基盤の製品は、もう十分に揃っています。それでも導入後に手作業が残るのは、自社で作った業務システムや古いオンプレミスのアプリが、SAMLにもOpenID Connectにも対応していないからです。

ここを放置すると、「主要なSaaSはSSOになったのに、基幹系だけ別パスワード」という状態が何年も続きます。私たちは、IdPの選定と並行して、自社システム側にSAML 2.0やOpenID Connectの受け口を実装する。Microsoft 365を使っている会社なら、Microsoft 365とEntra IDの導入・運用設計と一体で進めるのが近道です。

社員のIDと顧客のIDは、分けて設計します。自社サービスの会員情報や会員向け機能そのものは、会員管理システムの開発の領域。このページで扱うのは、社員と取引先が業務システムに入るための入口と、自社サービスのログインにSSOやパスキーを組み込む実装です。

ご提供する内容

ID・アカウントの棚卸し

どのシステムに、誰のアカウントが、どの権限で残っているかを一覧にします。退職者や用途不明の共有アカウントは、たいていここで見つかる。

IdPの選定と構成設計

Entra ID・Okta・Keycloakなどから、既存のライセンスと運用体制に合うものを選びます。クラウド型か自前運用か。判断の軸は、保守を誰が担うかです。

SSO(SAML・OIDC)の実装

SaaSは設定で、自社システムは受け口を実装してつなぎます。基幹系だけ別パスワード、という状態は残しません。

パスキー・多要素認証の導入

2026年8月25日にW3C勧告となったWebAuthn Level 3に沿って、パスキーを実装します。盗まれる前提のパスワードを、入口から減らす設計です。

入退社連動のプロビジョニング

人事の発令を起点に、SCIMでアカウントの作成と停止を各システムへ流す。管理画面を一つずつ開いて回る作業は、要らなくなります。

標準に非対応なシステムの連携改修

SAMLやSCIMに対応していない古いシステムには、アカウント連携用のAPIを後付けする開発で対応します。作り直すより先に、入口だけを揃える。

条件付きアクセスとログ設計

社外の端末や普段と違う場所からのログインには、追加の確認を求める。誰がいつどこから入ったかの記録は、監査で使える形で残す設計です。

認証まわりの点検と運用

作った入口に穴がないかは、第三者の目で確かめる脆弱性診断で点検できます。IdPの証明書更新や設定変更も、公開後の運用として引き継ぎます。

認証基盤ID管理のご提供内容
FAQ よくある質問
Q SSOを導入すると、情シスの業務は何が変わりますか?
A アカウントの停止と権限の変更を、IdP一か所で済ませられるようになります。システムごとに管理画面を開いて回る作業がなくなり、退職者のアカウントの止め忘れも起きにくくなります。社員側も覚えるパスワードが減るため、リセット依頼の問い合わせが減る方向に働きます。
Q Entra ID・Okta・Keycloakのどれを選べばよいですか?
A 既存のライセンスと、保守を誰が担うかで決まります。Microsoft 365を使っているならEntra IDが追加費用を抑えやすく、多数のSaaSを横断して管理したいならOktaのようなIDaaSが候補です。Keycloakはオープンソースで自前運用になるため、サーバーの保守とバージョン追随を社内か委託先で担える場合に向きます。
Q 自社開発の古い業務システムもSSOに対応させられますか?
A はい、対応できます。株式会社一創では、SAML 2.0やOpenID Connectに対応していないシステムに、IdPからの認証結果を受け取る仕組みを後付けで実装します。システム全体を作り直さずに入口だけを揃える方法を先に検討し、改修の範囲を小さく抑えます。
Q 同期型のパスキーは業務で使っても安全ですか?
A 多くの業務システムでは使えます。米国NISTのSP 800-63B-4(2025年8月公開)は、同期型パスキーをAAL2までの認証に利用できるとしています。一方で最も高い保証レベルのAAL3では、鍵を書き出せない認証器とフィッシング耐性が求められるため、特権管理者などには専用のセキュリティキーを使い分ける設計にします。
Q 退職者のアカウント停止を自動化できますか?
A できます。人事システムの退職情報を起点に、IdPからSCIM(IETFのRFC 7643・7644で定義された標準)で各システムへアカウントの停止を伝える形にします。SCIMに対応していないシステムには、停止用のAPIや連携処理を用意して同じ流れに組み込みます。
Q GビズIDで自社の業務システムにログインさせられますか?
A いいえ、できません。GビズIDのシステム連携はOpenID Connectを使いますが、デジタル庁の公式ガイドは連携対象を行政サービスとしており、民間システムとの連携は許可していません。自社システムの認証基盤には別のIdPを置き、行政との接点は公開されている行政APIや画面操作に限る設計にします。
Q ゼロトラストは認証基盤から始めるべきですか?
A 入口として認証基盤から着手するのが現実的です。NISTのSP 800-207は、ネットワーク上の位置に基づく暗黙の信頼を置かない考え方を示しており、判断の起点は利用者と端末の識別になります。IDが一つにまとまっていないと、アクセスの可否を条件で判断する仕組みも作れません。
Q 費用はどのように決まりますか?
A つなぐシステムの数と、そのシステムが標準仕様に対応しているかどうかで大きく変わります。株式会社一創では、SaaSの設定で済む範囲と改修が必要な範囲を棚卸しで切り分けてからお見積りします。IdP製品のライセンス費用は別途かかるため、既存契約で使える機能も合わせて確認します。
Q 導入期間はどのくらいかかりますか?
A 期間を左右するのは、対象システムの数、改修が必要なシステムの有無、段階的に切り替えるかどうかの3点です。全社員を一度に切り替えるより、部署や対象システムを区切って順に移すほうが混乱は小さく済みます。まず棚卸しで範囲を確定してから、切り替えの順番と期間をお伝えします。
Q 自社サービスの顧客向けログインにもパスキーを入れられますか?
A はい、組み込めます。株式会社一創では、W3CのWebAuthnに沿ったパスキーの登録・認証処理を自社サービスに実装し、既存のパスワードとの併用期間を設けて段階的に移行する形をご提案します。会員情報の管理そのものは会員管理システムの開発と合わせて設計します。

ご発注は請負・準委任・労働者派遣・ラボ型のいずれにも対応しています。
費用の考え方 | 開発の流れ | 契約形態の選び方 | 対応技術 | 対応パッケージ・ツール

開発会社・SIer の方はこちらのご案内もご覧ください。

OTHER SERVICE その他のWebシステム開発サービス一覧