社員が24個のパスワードを持つ会社には、24個の攻撃経路がある

ほとんどの企業は、セキュリティ侵害が起きるまで自社のアイデンティティ問題に気づきません。

退職した社員のアカウントが3つのシステムで有効なまま残っている——誰もオフボーディングチェックリストを更新しなかったからです。外部委託業者が財務ポータルにアクセスできてしまっている——6ヶ月前に「一時的な」アクセスが必要だとされ、チケットがクローズされないままだからです。フィッシング攻撃が成功してしまった——セキュリティが弱かったのではなく、チームが24個の別々のログインシステムを管理しており、そのうちひとつにMFAがないことを誰も気づいていなかったからです。

これは、社内システムを15〜30個運用している中規模事業者の多くが直面している現実です。怠慢ではありません。管理するためのインフラよりも速く、複雑性が成長してしまっただけです。

問題は「人」ではない

社員が複数のシステムでパスワードを使い回すのは、規律の問題ではありません——設計の問題です。退職した社員のオフボーディングにITが3日かかるのは、プロセスの問題ではありません——アーキテクチャの問題です。

独自のログインを管理するシステムは、それぞれが孤島です。各孤島には、固有のパスワード、固有のセッションルール、固有のアクセスリストがあります。そして各孤島は、互いに見えない存在です。

セキュリティリスクは静かに積み重なります:

倉庫主任が退職します。人事がMicrosoft 365アカウントを無効化します。しかし、ERPのログイン、レポートポータル、倉庫管理システムは別々の認証情報で動いており、誰も失効させることを思いつきません。
財務マネージャーのノートPCが盗まれます。ITはすぐにメールのパスワードをリセットします。しかし、売掛金ポータルは机の付箋に書かれた別のパスワードを使っています。
監査でQ3に財務データにアクセスしたユーザーのログが必要になります。各システムに独自のログがあります。ログがまったくないシステムもあります。

これらは仮定の話ではありません。分散したアイデンティティインフラが引き起こす、標準的な障害パターンです。

SSOが本当に解決するもの

シングルサインオン（SSO）は、ログインを便利にする機能ではありません。それはアイデンティティ制御レイヤーです——「この人物は誰で、何をする権限があるのか」という問いに答える責任を、ひとつのシステムに持たせるというアーキテクチャ上の決断です。

すべてのアプリケーションがその問いをひとつのIdentity Providerに委譲すると、いくつかのことが構造的に不可能になります:

ゴーストアカウントが消える。 社員がAzure ADで無効化されると、接続されているすべてのシステムが同時にアクセスを失います。チェックリストを待つ必要はありません。3日待つ必要もありません。即座に、自動的に。

監査証跡が一貫する。 すべてのログイン、すべてのセッション、すべてのアクセス試行がひとつのシステムを通ります。ひとつのログ。ひとつのクエリ。完全な全体像。

MFAが普遍的になる。 各アプリケーションにMFAが正しく設定されていることを期待する代わりに、アイデンティティレイヤーで一度だけ強制します。すべてのアプリケーションがそれを継承します。

認証情報の盗難が致命的でなくなる。 盗まれたパスワードが複数のシステムを解錠するとき危険です。SSOを使えば、社員は盗まれる複数のパスワードを持ちません——そして唯一の認証ポイントは、機密性の高いシステムに対してステップアップ認証を強制できます。

実際の動作

アーキテクチャはシンプルです。Identity Provider——この場合はMicrosoft 365にフェデレーションされたAuthentik——がすべての内部システムの前に配置されます。すべてのアプリケーションはログインのためにそこを向きます。AuthentikはユーザーのアイデンティティをAzure ADで確認します。

flowchart TD
    subgraph STAFF["👤 社員"]
        B[...]
    end

    subgraph PORTAL["🌐 アプリポータル"]
        AP[...]
    end

    subgraph AUTHENTIK["🔐 Authentik — Identity Provider"]
        AK[全システムへの\n唯一のログイン窓口]
    end

    subgraph AZURE["☁️ Microsoft 365 / Azure AD"]
        AAD[全アイデンティティの\n信頼できる情報源]
    end

    subgraph APPS["24のシステム"]
        direction LR
        T1["🖥️ ERP · 財務 · 倉庫\n文書管理 · HRポータル"]
        T2["📱 メール · 電話 · メッセージ"]
        T3["🖨️ プリンター · ハードウェア"]
    end

    B -->|"1回のログイン"| AP
    AP -->|"このユーザーは誰？"| AUTHENTIK
    AUTHENTIK -->|"アイデンティティ確認"| AZURE
    AZURE -->|"確認済み"| AUTHENTIK
    AUTHENTIK -->|"アクセス許可 + ロール"| APPS

    style AUTHENTIK fill:#EBF3FB,stroke:#2E75B6,stroke-width:2px
    style AZURE fill:#E8F4E8,stroke:#375623,stroke-width:2px
    style STAFF fill:#FFF9E6,stroke:#7F6000,stroke-width:2px
    style PORTAL fill:#FFF9E6,stroke:#7F6000,stroke-width:1px
    style APPS fill:#F5F5F5,stroke:#999999,stroke-width:1px

社員はこれを一切意識しません。ポータルを開き、必要なアプリをクリックすれば入れます。その朝すでにMicrosoftアカウントにログインしていれば、ログイン画面すら表示されません。

初回ログイン時の動作:

sequenceDiagram
    actor Staff as 社員
    participant Portal as アプリポータル
    participant Authentik as Authentik
    participant Azure as Azure AD
    participant App as 24システムのいずれか

    Staff->>Portal: ブラウザを開く
    Portal->>Authentik: セッションなし
    Authentik->>Azure: MS365ログインへリダイレクト
    Azure-->>Staff: メール + パスワードを入力
    Staff->>Azure: 認証（+ MFA）
    Azure-->>Authentik: アイデンティティ確認済み
    Note over Authentik: グループ確認、ロール適用、<br/>MFAポリシー強制
    Authentik-->>Staff: セッション確立 ✓
    Portal-->>Staff: パーソナライズされたアプリタイルを表示

    Staff->>App: タイルをクリック
    Note over Authentik: セッション存在済み — ログインをスキップ
    Authentik->>App: ロール付きアクセストークンを発行
    App-->>Staff: アクセス許可 ✓

それ以降のすべてのログイン:

sequenceDiagram
    actor Staff as 社員
    participant App as 24システムのいずれか
    participant Authentik as Authentik

    Staff->>App: アプリを直接開く
    App->>Authentik: セッション検証
    Note over Authentik: セッション有効 — ログイン不要
    Authentik->>App: アクセストークン発行
    App-->>Staff: アクセス許可 ✓ — パスワード入力なし

裏側では、Identity Providerがすべてのリクエストで相当な処理をしています: セッションの検証、グループメンバーシップの確認、MFAポリシーの強制、ロール固有のクレームをアクセストークンへの注入、統合監査ログへの書き込み。

アプリケーション側の統合は軽量です。各システムはクライアントIDとクライアントシークレットを受け取ります。認証エンドポイントのすべてをひとつの設定URLから自動検出します。ユーザーが到着すると、アプリケーションはIdentity Providerに保証を求めます。Identity Providerはアプリケーションが必要とするすべて——アイデンティティ、グループ、ロール、アクセスレベル——を含む署名済みトークンで応答します。

カスタム作業は最小限です: 既存のAzure ADグループをアプリケーション固有のロールにマッピングし、機密システムにステップアップMFAを設定し、各ユーザーがアクセスを許可されたアプリケーションだけを表示するポータルタイルランチャーを構築します。

オフボーディング問題の解決

SSOの最も過小評価されているメリットは、誰かが退職したときに何が起きるかです。

分散したシステムでは、オフボーディングはチェックリストです。誰か——たいていはIT、ときに人事、ときに誰もいない——がシステムのリストを順番にたどり、手動でアクセスを失効させます。システムが見落とされます。新しいアプリケーションが追加されてもチェックリストは更新されません。リストを管理していた人は半年前に退職しています。

SSOとSCIMプロビジョニングを使えば、オフボーディングはプロセスではなくイベントになります。Azure ADでアカウントが無効化された瞬間、SCIMプッシュがその変更をIdentity Providerに伝播します。アクティブなセッションが無効化されます。接続されているすべてのアプリケーションがそのアイデンティティを受け付けなくなります。24システムすべてが、チェックリストなしに、同時に。

sequenceDiagram
    participant HR as 人事 / マネージャー
    participant Azure as Azure AD
    participant Authentik as Authentik
    participant Apps as 24システムすべて

    HR->>Azure: 社員アカウントを無効化
    Azure->>Authentik: SCIMプッシュ — アカウント無効化
    Note over Authentik: アクティブセッションをすべて無効化
    Authentik-->>Apps: 24システム全体でアクセス失効
    Note over Apps: 同時に。チェックリストなし。<br/>見落としなし。忘れたシステムなし。
    HR-->>HR: 完了 ✓

代替案と比べてみてください: 社員がどのシステムにアクセスしていたかを知らないかもしれない人が、最後のIT引き継ぎ以来更新されていないリストをもとに、システムごとに手動で処理するチェックリスト。

社員の入れ替わりが多い企業——食品製造や流通業では一般的です——にとって、これは些細なことではありません。無効化されたアカウントが本番システムにアクセスできる状態のまま1日過ごすことは、それ自体がリスクです。

導入に向けて期待できること

24システムに対して適切にスコープされたSSO導入は、エンドツーエンドで約10週間かかります。フェーズは予測可能です:

最初の2週間は基盤を構築します: Identity Providerのインストール、Microsoft 365テナントへの接続、フェデレーションが正しく機能することの確認。まだアプリケーションは移行されません——このフェーズは純粋にインフラです。

3〜4週目で24のアプリケーションすべてを接続します。各アプリケーションにクライアントID、リダイレクトURI、アクセスポリシーが登録されます。グループベースの認可が設定されます。設定はバージョン管理されたYAMLブループリントとしてエクスポートされます——再現可能で監査可能です。

5週目でカスタム作業を処理します: Infor M3のようなアクセストークンにアプリケーション固有の属性が必要なシステムのERPロールマッピング、機密システムのステップアップMFAポリシー。

6週目でユーザー向けレイヤーを提供します: アプリケーションポータル、日本語ローカライズ、すべての認証画面への会社ブランディング。

7〜8週目でコミュニケーションツールを接続します——電話システム、メッセージングプラットフォーム——各社員のアプリケーションアカウントをAzure ADアイデンティティに紐付けるアカウントリンクステージを通じて。

最後の2週間はテスト、ユーザー受け入れ、引き継ぎです: アプリケーションごとの完全なテスト計画、ITチームとのファシリテートされたUATセッション、アーキテクチャ、管理手順、緊急アクセスプロトコルをカバーする完全なドキュメントパッケージ。

問うべき問い

あなたの組織が集中型アイデンティティ管理を必要としているかどうかという問いではありません。10以上の内部システムを運用しているなら、もう必要です。

問いは、その必要性に何かが壊れる前に気づくか、後に気づくかということです。

MFAのないレガシーERP、倉庫システムでまだアクティブな退職者の認証情報、12のアプリケーションにログが分散しているために応答できない監査要求——これらはエッジケースではありません。アーキテクチャなしに拡張されたアイデンティティインフラの、予測可能な結果です。

SSOはすべてのセキュリティリスクを排除しません。しかし、分散から生じるリスクの特定カテゴリを排除します: ゴーストアカウント、静かな認証情報の使い回し、オフボーディングのギャップ、監査のブラックホール。

Microsoft 365で運用している組織には、基盤はすでにあります。Azure ADはあなたがすでに支払っているアイデンティティ機関です。作業は残りの23のシステムをそれに接続すること——そしてその接続が堅牢で、監査可能で、集中管理されていることを確認することです。

既存のシステムを統合SSOレイヤーに接続することにご興味がありますか？私たちはMicrosoft 365を運用する組織と連携し、Authentikベースのアイデンティティインフラを導入しています——OIDC、SAML2、LDAP、ERPおよびコミュニケーションツール向けのカスタム統合をカバーします。あなたの環境についてご相談ください。

関連サービス