入り口を一つにまとめたSSOによる本人確認の重要性とは?

入り口を一つにまとめたSSOによる本人確認の重要性とは?

本のまとめ

▼読んだ本は?
■成長する企業はなぜSSOを導入するのか
■日本ヒューレット・パッカード株式会社
http://amzn.asia/d/0tBAHQp
▼認証と認可とは?
■認証=「本人確認」のこと
└具体的には「IDカード提示」「パスワード入力」「人の目によるチェック」などさまざまな方式がある

■認可=「アクセス許可」のこと
└特定の場所に立ち入ることができる、特定のコンテンツを閲覧できるようにするなどアクセス許可を与えること

▼SSOとは?
■SSO(シングルサインオン)とは、本人確認を行うための認証入り口を企業サイト/業務システム間で一つに統合すること
■SSOを導入するということは、企業サイト/業務システムへの入り口を「1つの扉」のみにすること
■1つの扉のみになれば、その扉のセキュリティレベルを向上させれば良いなど統合できる
▼SSO導入が必要になるのはなぜ?
以下のようなシチュエーションが発生するから

【1】偽サイトからのパスワード漏洩事例
■社員がプライベートで本物とそっくりのニセ銀行サイトなどを訪れ、パスワードを入力してしまう
■盗まれたパスワードと、社内で使う業務システムのパスワードが同じだった
■同じパスワードを複数サイトで使いまわしてしまっていたことにより会社システムに侵入されてしまう

【2】企業統合時に業務システム数が増大事例
■企業合併した際に扱う業務システム数が増加
■1人の社員が覚えなければならないパスワードが急増
■社員がパスワードを覚えることに疲弊し、結果生産性が下がってしまった

【3】クラウドサービス利用時の認証ポリシー事例
■クラウドシステムを利用するユーザーに対し認証ポリシーが未確定
■不正アクセス防止のためのポリシー策定に多大な時間をとられる
■クラウドサービス提供者側の認証方式にも制限あり
■結果利用するユーザーに対して、ややこしい認証フローを求めてしまう

▼SSO実現の3つの方法は?
【1】リバースプロキシ方式
■ユーザーと企業サイト/業務システムの間に「リバースプロキシサーバー」と呼ばれる代理サーバーを配置すること
■ユーザーからの認証リクエストが来ると、リバプロサーバーはID/パスワード/アクセス権限などを管理する認証サーバーに対して中継を行う
■各企業サイト/業務システム自体はリバプロサーバーの背後に隠れるため、各サービス毎の脆弱性対策の手間を削減できる
■今後企業サイト/業務システムを新規開発した場合、認証機能の開発自体を省略可能

【2】エージェント方式
■企業サイト/業務システムが稼働しているサーバーにエージェントモジュールを直接組み込む方式
■ユーザーから認証リクエストがあると、エージェントモジュールがサービス自体に変わって認証サーバーと連携し認証判定を行う
■ユーザーリクエストが各企業サイト/業務システムに分散するため、ネットワーク負荷が集中することがない

【3】クライアントエージェント方式
■各ユーザー側の端末にエージェントモジュールをインストールし、個々の企業サイト/業務システムログイン画面をエージェントが検知することで、ユーザーIDやパスワードを自動投入する方式

【4】フェデレーション方式
■「SAML」「OpenID Connect」など標準規格を利用し認証を行う方式
■「認証連携」とも呼ばれる
■外部サービスとの認証連携や、新しいクラウドサービスを利用するときに認証連携として利用される

▼フェデレーション方式で利用される「SAML」「OpenID Connect」規格とは?
【1】SAML規格
■「自社認証システム=IdP(Identy Provider)」「クラウドサービス=SP(Service Provider)」と呼ぶ
■SAMLの具体的な流れは以下
【1】ユーザーがIdPにアクセスしてパスワードなどで認証を行う
【2】IdPがアサーションと呼ばれるパスポートのようなものをユーザーに発行
【3】アサーションがWEBブラウザを介してSPに提示
【4】アサーションの正当性と信頼したIdPによる発行かをSPが確認
【5】SPがユーザーに利用を許可する

【2】OpenID Connect規格
■「自社認証システム=OP(OpenID Provider)」「認可を受ける側=RP(Relying Party)」と呼ぶ
■例えばクレジットカード情報を認証する側がOP、認可を取得してFinTechサービスを提供する側がRPとなる
■OpenID Connectの具体的な流れは以下
【1】ユーザーがFinTechサービスにアクセスしてパスワードなどで認証を要求する
【2】FinTechサービスが金融機関の自社認証システムへユーザーの認証を要求する
【3】金融機関の自社認証システムがユーザーの認証を行う
【4】金融機関の自社認証システムが認証済みであることを示す認可(トークン)の発行と、ユーザー情報をFinTechサービスにわたす
【5】Fintechサービスは金融機関のリソースサーバーのオープンAPIにアクセスし、受け取ったトークンを提示しサービス提供に必要な追加情報を受け取る

※SAMLやOpenID Connectを利用する場合、受け手となるクラウドサービス側でもフェデレーションに対応した仕組みを保持している必要がある

▼SSO導入により使える機能は?
■代行ログイン機能
└SSOシステムが、ユーザーの代わりにIDやパスワードを送信する機能
└送信されるID/パスワードはユーザーがSSOシステムに以前ログインした時のものか、予めSSOシステムに登録しておいたもののいづれか

■ログインセッション管理機能
└ユーザーが各企業サイト/業務システムに以前ログインし訪問したことがあるかに関して、SSOシステム側が一括して管理する機能

■情報継承機能
└各企業サイト/業務システム内にてユーザーから取得した情報を、SSOシステム側にて統合して保存/管理する機能

■アクセス制御機能
└各コンテンツへのアクセスの可否を制御する機能

■アクセス記録機能
└各企業サイト/業務システムへのログイン状況やアクセス状況のログをSSOシステム側で記録する機能

■Windows認証との連携機能
└WindowsPCにログオンしたユーザーに対して、SSOシステムへのログインを不要にする機能

▼広がる多様な認証方法は?
【1】ソーシャルログイン
■SNSと認証連携して、顧客が新規会員登録を行うことなく新たなサイトを利用できる仕組み
■新たな登録ユーザーを呼び込みやすくなることに加え、サイト内での認証の仕組みを簡易化できる

【2】ワンタイムパスワード
■一度限り使用できる使い捨てのパスワードのこと
■毎回異なるパスワードが生成されるため他人に知られても、なりすますことはできない
■パスワードを生成する「トークン」と呼ばれるハードウェア、もしくはPCやスマートフォンで利用するソフトウェアが必要

【3】生体認証
■指紋、音声、虹彩、顔の特徴など生体で本人確認を行う方法
■手をかざす、カメラを見るなどユーザーに求められる操作が簡単
■一度コピーされてしまうと、二度と変更することができないなど問題も存在

【4】端末情報/位置情報
■端末固有の識別番号などの固有の情報や、位置情報などで本人確認を行うこと
■単体で導入するよりかは、他の認証方法と一緒に使い、セキュリティレベルを向上する形で使われる

▼SSOシステム導入時のポイントは?
■可用性
└複数サービス間のログインセッションを統合管理するため、高い可用性が必要

■性能拡張性
└今後企業サイト/業務システムが増えていくことを踏まえ、「スケールアップ」「スケールアウト」などの方法で性能を向上させられるかの検討が必要

■運用管理性
└SSOシステムはユーザーと複数サービス間の中間に入ってくるため、問題が起こったタイミングで一番初めにやり玉にあがることが多い。そのため、今後の運用方法を予め深く検討必要

▼SSOシステムの導入方法は?
【1】商用パッケージ
└◯:最新のセキュリティ対策、また認証規格を利用できる
└☓:細かなカスタマイズがしづらい

【2】スクラッチ開発
└◯:個別案件にあったカスタマイズができる
└☓:セキュリティ対策や新しい規格への対応が後手に回りやすい

【3】オープンソース(OSS)
└◯:新技術への対応が早く、ソースコードが公開されているためカスタマイズできる
└☓:オープンソースのためセキュリティ面や開発コミュニティの突然の閉鎖などの危険がある

【4】クラウドサービス(IDaaS)
└◯:安価にスモールスタートでき、セキュリティ対策に関してもクラウド提供側に任せられる
└☓:オンプレミスとの連携が難しい場合があること、またID/パスワードをクラウド上に保管する形となる

▼SSOシステムの構成とは?
【1】フロントモジュール
└ユーザーからのアクセスを直接受けるモジュール
└「ログインセッション管理機能」「権限管理機能」など多くの機能をフロント側に持たせる形を「FAT型」と呼ぶ

【2】バックエンドモジュール
└認証データベースとの接続などを担うモジュール
└「ログインセッション管理機能」「権限管理機能」など多くの機能をバック側に持たせる形を「THIN型」と呼ぶ
└フロント側に問題が発生した場合にも、ログインセッション等を保持できる
└バック側に処理が集中するため、インフラとして高い可用性が必要

思ったこと

企業サイト/業務システムとユーザーをつなぐ時の本人確認、確認後のアクセス許可を一箇所に統合するSSOシステムに関して、そもそもSSOがなぜ必要なのかから始まり、その導入方法、導入時に気をつけるべきポイントなどをまとめた本でした。

SSOは一見、ユーザーへの入り口を一つにしてしまうため簡単に内部に入られてしまうようにも思えてしまいます。けれどほとんどの人は覚えるのが大変なことから、複数システム間のログインパスワードを同じものにまとめてしまっています。だからこそ、セキュリティが予め担保された一つの入り口を用意し、その入口に厳重な鍵をかけて、ユーザーの本人確認をしっかり行おうという考えがSSOシステムには反映されています。

セキュリティとかって、すんごく地味だし問題が起こるまでは誰もお金をたくさん使ってでも気をつけようという意識すらもたないことがほとんどだけれど、セキュリティを担保せず結果最悪の自体に陥った会社とかもよくニュースになるように、本質的には最も大事な部分の一つなんだなと思いました。

とりあえず毎日家の窓のカギかけ忘れてるぼくは、そっからはじめよう。

ありがとうございました!

関連する記事