電子認証（本人認証）の方式検討 のバックアップ(No.3)
- バックアップ一覧
- 差分 を表示
- 現在との差分 を表示
- ソース を表示
- 電子認証（本人認証）の方式検討 へ行く。
- 1 (2020-08-10 (月) 15:36:16)
- 2 (2020-08-10 (月) 15:48:33)
- 3 (2020-08-11 (火) 13:19:45)
- 4 (2020-08-19 (水) 15:43:55)
本項では、電子認証の内、特に情報システム開発で重要となる本人認証の方式を検討するための、考え方やプロセスについて解説します。
システム構築における電子認証に関する基本的な考え方 †
電子認証とは、オンライン上の業務システムやサービスに対して、本人とIDに関連付けられた Authenticator（パスワードや証明書などの認証子）を使い、本人に代わって Authenticator が正当な本人であることを認証システム (Verifier) に対して証明します。この Authenticator が適切に管理されず、例えばパスワードが外部に流出すれば成りすましを許すため、以下の点を考慮して、取り扱うデータと Authenticator の適切な組み合わせを検討する必要があります。
- 取り扱うシステムやデータ資産の重要度や漏洩や改ざんなどのインパクト
- 取り扱うシステムやデータ資産にアクセスできる人（職務権限や業務上の役割）、もしくはバッチ処理等でアクセスするシステムの特定
- アクセスする際の Network や物理的領域での制限
- Authenticator の特性と危殆化（漏洩等）した際のリスク
- シークレット（パスワード、証明書等）を、変更・再発行する際の Verifier のリスク 特に、①と②の明確化がなされた上で、初めて認証方式の検討が行われるべきであるといえます。
電子認証に使用されるAuthenticatorの種類と課題 †
Authenticator の種類 †
以下に代表的な Authenticator をあげます。
| 種類 | 認証要素 | 内容 |
| パスワード | 知識 | ユーザーが記憶するもの。PIN（暗証番号）も含まれる。 |
| ルックアップシークレット | 所有 | 乱数表やリカバリコード表。ファイルもしくは印刷物。 |
| 経路外デバイス | 所有 | スマートフォンのSMSによるコード送信、QRコードの読み取り。 |
| 単一要素ワンタイムパスワードデバイス | 所有 | ワンタイムパスワード発生器、もしくはソフトウェア。 |
| 多要素ワンタイムパスワードデバイス | 所有+知識/生体 | パスワードなどを入力すると稼働するワンタイムパスワードデバイス。 |
| 単一要素暗号ソフトウェア | 所有 | 端末に保存されたクライアント電子証明書。 |
| 単一要素暗号デバイス | 所有 | FIDO U2FのUSBドングル。 |
| 多要素暗号ソフトウェア | 所有+知識/生体 | 指紋認証などで有効化されるクライアント電子証明書。 |
| 多要素暗号デバイス | 所有+知識/生体 | パスワード、生体認証で有効化されるクライアント電子証明書が納められたUSBトークン。 |
NIST SP800-63-3翻訳版63-Bパートの紹介を参考にしました。https://www.slideshare.net/kthrtty/20171027-nist-sp80063bkthrtty-81333156
Authenticator に対する脅威 †
以下にAuthenticator ごとの脅威と対策をあげます。パスワードに関する詳細な課題については、第3章で解説します。
| 種類 | 脅威 | 対策 |
| パスワード | 総当たり攻撃、辞書攻撃による突破。 | ロックアウト設定。Soltを加えたHashデータの保存。 |
| パスワードを書いたメモやファイルの開示。 | ユーザー教育。罰則を伴う運用規程の施行。 | |
| キーロギングによる盗聴。 | アンチウイルス、EDR等での検出。 | |
| フィッシングサイトでの漏洩。 | サンドボックス、Webフィルタリングの導入。 | |
| ショルダーハッキング。 | ユーザー教育。のぞき見防止フィルターの導入。 | |
| 上司や管理者を装った攻撃者からの問い合わせによる漏洩。 | ユーザー教育。 | |
| Pass the Hash攻撃による盗聴、漏洩。 | Credential Guardの導入。多要素認証の導入。 | |
| ルックアップシークレット | 紛失、盗難、複写による漏洩。 | 封緘し、鍵のかかるロッカー、金庫での保管。 |
| 経路外デバイス | 紛失、盗難による漏洩。 | スマートフォン等のアカウント凍結、再発行。 |
| 単一要素ワンタイムパスワードデバイス | 紛失、盗難による漏洩。 | アカウント凍結、再発行。 |
| 多要素ワンタイムパスワードデバイス | 紛失、盗難による漏洩。 | アカウント凍結、再発行。 |
| 単一要素暗号ソフトウェア | 紛失、盗難による秘密鍵の漏洩。 | 秘密鍵のエクスポート禁止設定。P12形式ファイルをCD-ROM等に記録し、封緘の上、金庫で保管する。 |
| 単一要素暗号デバイス | 紛失、盗難による漏洩。 | 公開鍵の失効もしくはアカウント凍結、再発行。 |
| 多要素暗号ソフトウェア | 紛失、盗難による漏洩。 | 公開鍵の失効もしくはアカウント凍結、再発行。 |
| 多要素暗号デバイス | 紛失、盗難による漏洩。 | 公開鍵の失効もしくはアカウント凍結、再発行 |
脅威からAuthenticator を守る手段 †
Authenticator を脅威から守る手段として、多要素の利用、物理的な制限、ネットワーク制限などが考えられます。これらを複合的に利用することで、脅威を排除します。ここでは、パスワードを利用する際の強化策をあげます。
- スマートカード、スマートフォンのSMSなどの多要素認証の利用
- 社員証などによる物理的な入退出管理が伴う領域での端末、サーバーでの利用
- IPアドレス制限、端末制限
- Windows における Credential GuardなどのPass The Hash 対策の実施
- ATP、EDRの導入によるエンドポイント監視、SIEMでの監視の実施
- ロールベースアクセス制御 に基づくリスクマネジメントの実施
パスワード以外の認証方式の課題 †
スマートカードを含む端末と分離可能なデバイス †
所有するデバイスは、盗難・紛失に関わるリスクが存在します。
- 紛失・盗難の際の失効 紛失・盗難の際はデバイスを失効させ、他人の操作を受け付けないようにしなければなりません。
- 再配付における安全な輸送手段、本人確認
紛失や盗難があった場合、再発行までの期間は代替の認証方式を用意する必要があります。また、再配付に際して、安全・確実な輸送手段の確保と、本人に確実に配付する方法の確立という運用面での課題があります。
スマートカード †
スマートカードは多要素認証の代表格であり、単一認証に比べればはるかに強固な認証ソリューションを提供します。スマートカード（所有）とPIN（知識）という組み合わせが必要なため、たとえPINが漏洩してもスマートカードがなければ攻撃が成功しないとされています。
- スマートカードログオンでの Pass The Hash 攻撃
しかし、スマートカードログオンでも、Windows の場合は NTLM ハッシュを生成されることから、NTLM ハッシュを悪用するPass The Hash攻撃に対して万全ではありません。NTLM ハッシュが窃取されてしまえばスマートカードがなくてもログオンは成功します。従って、スマートカードアカウントの定期的なハッシュのローテーションは必須であり、Credential Guard などのソリューションを組み合わせることで、NTLMハッシュを保護しなければ、期待される効果が発揮されません。 - 自営認証局
自営で認証局 (CA) を保有する場合、ルート認証局が署名した中間認証局から証明書を発行したうえで、ルート認証局の秘密鍵をハードウェア・セキュリティ・モジュール (HSM) に保管し、オフラインにしておくなど管理が必要です。 - 適切な有効期間
証明書の有効期間が短いと更新が頻繁に起こり、管理負担が増加します。一方で、有効期間の長い証明書を大量に発行しかつ失効すると、有効期限が切れるまでCRL（失効リスト）に収録されるため、CRLのサイズが大きくなり、ログオンの際のトラフィックの増大につながるため注意が必要です。
生体認証 †
生体認証は顏、指紋、静脈などの生体情報を使った認証であり、スマートカード（所有）やハードウェアワンタイムパスワード（所有）に比べて持ち歩く必要がなく、紛失や盗難などが起こらないというメリットがあります。しかし、生体情報が漏洩した場合、代替が困難なことから、認証側での生体情報の管理を厳重にする必要があります。また、生体認証は誤認識による他人受入や本人拒否の可能性があり、確率に基づく認証方式といえます。ゆえに重要な情報資産を扱う場合は（知識）や（所有）など、他の要素との組み合わせが必須となってきます。以下に生体認証に関する脆弱性の一覧 をあげます。
| 脆弱性 | 概要 |
| 他人受け入れ | 自分の生体情報をそのまま提示した場合、他の利用者として偶然受け入れられてしまう。 |
| 狼(wolf) | 複数のテンプレートに対して、高確率で他人受入を可能にする生体情報を有する利用者（狼）が存在する。 |
| 子羊(lamb) | 複数の生体情報に対して、高確率で他人受入を可能にするテンプレートを有する利用者（子羊）が存在する。 |
| 類似性 | 双子等、類似の生体情報を有する人が複数存在してしまう。 |
| 偽生体情報 | 生体情報を物理的に偽造し、それが受け入れられてしまう。 |
| 公開 | 生体情報が本人の同意なく容易に他人の手に渡ってしまう。 |
| 推定 | テンプレートや照合結果が生体情報推定の手掛かりとなる。 |
| 利用者状態 | 被認証者の生体情報が自身の事情で変化し、システムに受け入れられない。また、そうした品質の劣る生体情報を登録することによって、他者になりすましされてしまう。 |
| 入力環境 | 被認証者の生体情報の読取データが環境要因で変化し、システムに受け入れられない。また、そうした品質の劣る生体情報を登録することによって、他者になりすましされてしまう。 |
| 認証パラメータ | 不適切な認証パラメータの設定によって他人受入の可能性が高まる。 |
出典：生体認証システムの脆弱性の分析と生体検知技術の研究動向 : https://www.imes.boj.or.jp/research/papers/japanese/kk28-3-4.pdf
そのほか認証に関する留意点 †
本項では認証全般に関する留意点を解説します。
E-Mailは経路外認証とはならない †
NIST SP800-63-Bでは、スマートフォンを使った経路外認証は、検討当初は非推奨でしたが、最終的に ”RESTRICTED” となりました。事前登録済の電話番号が物理デバイスと結びついていることを確認した上で、Authenticator ソフトや SMS にワンタイムパスワードを送信することは問題ありませんが、E-Mail を使った場合は、特定デバイスの所有の証明とはならないため経路外認証とはならず、多要素認証を構成できません。
ID管理 †
- デフォルトの弱いID、パスワードの変更
Administrator、Admin、Adm、root、Su などの、OS、データベース、通信機器などのデフォルトのIDは、総当たり攻撃の際に使用されるため、変更可能な場合は、初期設定時に必ず変更しておく必要があります。IDを変更できれば、総当たり攻撃に対する耐性が確保できます。
OS、ルーター等のデフォルトのパスワードは、インターネット上に公開されており、必ず変更しておく必要があります。 - Windows における Administratorの変更 グループポリシーによって、Administratorを異なるIDに変更します。Administrator利用し続けること、共有利用することは、以下の理由から禁止すべきです。
- 攻撃の対象になりやすい
- ログ等でオペレーターを特定できず、改ざんや成りすましの発見が困難となる
- 退職者が出た際にパスワードの変更が必要となり、類推可能なパスワードの変更が発生したり、記憶されるまでメモ書き等の露出の可能性が高まる
開発者のIDは削除する †
開発中に使用した開発者のID、テスト用のIDなど、運用に不要なIDは必ず削除してください。
機器間認証 （Machine To Machine） †
機器同士の通信の場合、IDやパスワードがハードコードされるケースが散見されますが、危険です。アクセス権限が設定された外部ファイルに暗号化して保存するなど、変更したい場合にはいつでもリモートで変更できるような構成が必要です。また、デフォルトのIDのまま初期設定されると、1.3.2項同様に総当たり攻撃に対して脆弱となりますので、導入設置時には変更を強制する認証システムの実装が必要です。 PKIを使用する際は、証明書の有効期限切れのないように期限管理に留意してください。
特権ID、パスワードの保管・管理 †
管理者が利用する特権IDとパスワードなどが記載されたドキュメントを保管する場合は、オフラインが原則です。サーバーや端末には保存せず、CD-ROM等の外部メディアに保存し、CD-ROMケースに封緘して鍵のかかる金庫に保管してください。紙に記録した場合も、同様に封筒に入れて封緘し鍵のかかる金庫に保管します。
ID、パスワード、センシティブ情報のハードコードの禁止 †
ID、パスワードやセンシティブな情報をソースコードに直接書き込まないでください。ハードコードされたID、パスワードなどはプロジェクトに参加した開発者全員が知ることとなり、その時点で危殆化していると考えるべきです。開発時の保全が出来たとしても、運用に入った後で、パスワードが危殆化した場合、ソフトウェアをバージョンアップする必要が出ます。攻撃者がバイナリにアクセスできる場合、逆アセンブルすることでID、パスワードなどの漏洩につながります。対策として、JPCERT/CCの実装例 : JPCERT/CC Java コーディングスタンダード CERT/Oracle版 https://www.jpcert.or.jp/java-rules/msc03-j.html を参照してください。