SSOに対応しないアプリ、アカウント管理はどうするか

SSOを導入しても片づかない問題が一つ残ります。会社が使うアプリのかなりの部分は、依然としてSSOに対応していないという点です。特に国内外の中小SaaS、古い業務ツール、特定ベンダーのポータルは、標準のSSO連携を提供していない場合が少なくありません。そして、まさにこうしたアプリでアカウント管理が最も手薄になります。

共有アカウントという静かな危険

SSOに対応しないアプリは、たいていこう管理されます。チームが一つのアカウントを共同で使い、パスワードはチャットやスプレッドシートに書かれて出回ります。この方式には三つの問題があります。

一つ目は、誰がアクセスしたか分からないことです。アカウントが共有されているため、ログを見ても実際の利用者を特定できません。二つ目は、回収ができないことです。チームメンバーが抜けてもパスワードを変えなければアクセスは残り、変えれば残った全員が新しいパスワードを再共有しなければなりません。三つ目は、パスワードが平文で出回ることです。チャット履歴やドキュメントに残ったパスワードは、漏洩の定番の経路です。

SSO審査を通過した会社でも、この領域はそのまま放置されている場合が多くあります。標準プロトコルでつなげないため、手のつけようがないからです。

資格情報vaultと自動ログインというアプローチ

この問題に対処する方式が、資格情報vaultと自動ログインです。一般にSWA(Secure Web Authentication)と呼ばれます。

核心となる考え方はこうです。アプリのIDとパスワードを人ではなく暗号化されたvaultに保管し、社員はそのパスワードを直接見ることなくログインだけできるようにします。ログインは、ブラウザ拡張がvaultから資格情報を受け取って代わりに入力する方式で処理されます。社員にとってはクリック一つでログインでき、会社にとってはパスワードが人の手を経由しません。

このアプローチの利点は明確です。パスワードは暗号化されて保存され、チャットで出回りません。誰がどのアプリにアクセスしたかが中央で記録されます。そして社員が抜けたら、vaultで資格情報へのアクセスを断つだけでよいため、アプリごとにパスワードを変えて回す手間がなくなります。

導入時に考慮する点

• 資格情報が暗号化保存されるか、そして誰が復号できるか
• 個々のユーザー単位でアクセスの付与・回収ができるか(共有アカウントの限界を越える核心)
• ログイン・アクセスのイベントが監査ログに残るか
• ブラウザ拡張の権限範囲が必要な分だけに制限されているか

特に最後の項目が重要です。自動ログインは便利な分、拡張が広い権限を持ちやすいため、権限範囲を最小化する製品を選ぶほうが安全です。

AxiPassはこの領域を覆います

AxiPassのSWAは、SSOに対応しないアプリの資格情報をLockboxのカラム暗号化で保管し、ブラウザ拡張を通じて自動ログインを提供します。資格情報はユーザーごとに付与・回収でき、共有アカウントを個人単位のアクセスに変えられます。自動ログインの実行と資格情報の使用イベントは監査ログに残ります。アプリ内の活動記録は、必要に応じてオプションで有効にできます。ログアウト時には拡張とSWAセッションの終了まで併せて伝播されます。標準SSOでつながるアプリはOIDC/SAMLで、そうでないアプリはSWAで管理すれば、社内アプリ全体を一つのコンソールの下にまとめられます。

SSOのないアプリまでどう管理されるかをご自身でご覧になりたい方は無料で始めるから確認できます。社内アプリの構成に合った方法が必要な方は導入相談からお問い合わせください。