認証システムの基礎知識

認証システムとは、ユーザーの正当性をチェックし、アクセスを許可したり拒否したりするシステムです。本連載では、6回シリーズで、認証システムについて取り上げます。最近、認証に関連して、さまざまな事件や事故が発生しています。情報（サイバー）セキュリティにおいて、最も基本的な要素の一つである認証を理解したうえで、適切な管理、運用、利用を行うことが重要です。第1回は、認証の役割と、認証に対する脅威を解説します。

もくじ

第1回：認証を考える

1. コンピュータとサービスにおける「認証」の位置付け

コンピュータやネットワークサービスのセキュリティを考える上で、特に重要かつ基本的な要素として、以下の3つが挙げられます。

すなわち、誰にどのような利用を許可する必要があるかを元に、利用者IDを発行し、そのIDで利用可能な機能（権限）を定めます。システムは、IDを入力した利用者が、IDを発行された本人であるかどうかを認証によって判定し、本人確認できれば、あらかじめ決められたシステム上の権限を付与（認可）します。利用者が実際に行う操作は、ここで付与された権限の範囲で許可され、それ以外の操作は禁止されます。これを、アクセス制御といいます（図1）。

利用者がシステムを利用する必要がなくなれば、発行されたIDを無効化して、それ以降利用できなくする必要があります。利用する内容や目的が変わった場合は、それに応じて、与える権限を変更しなければなりません。そうしなければ、不要、もしくは不適切なアクセスを利用者に許してしまうことになります。認証やアクセス制御は、IDと付与された権限に基づいて機械的に行われるため、管理がずさんでは、セキュリティの土台が崩れてしまいます。

認証は、利用者の本人確認を行うステップです。システムの内部で、利用者はIDによって管理されます。正式なIDを使用していれば、無条件にそのIDに対して与えられた権限を行使できます。そのため、最初の関門である認証は、……

>>第1回 第1章の続きを読む（PDFダウンロード）

2. 認証への脅威

認証に対する脅威の大きさは、システムが提供する機能や情報の価値に依存します。認証を破ってシステムを不正利用することで得られる利益が大きいほど、脅威は大きくなります。例えば、オンラインバンキングのようなサービスでは、直接、金銭的な利益に結びつくため、犯罪組織のような手ごわい相手からの攻撃を防がなくてはいけません。同様に、ネット販売ウェブサイトなどにおいても、得られる利益が大きければ、常にさまざまな攻撃にさらされることになります。

直接、金銭的な利益が得られなくても、そのコンピュータやサービスから得られる情報が価値を持つ場合もあります。個人情報、とりわけクレジットカード情報などが含まれるシステムにおいては、そうした情報を狙った攻撃にも留意が必要です。

インターネットから直接アクセスができないシステムでも、油断はできません。近年、特定の企業などの内部情報を狙ってマルウェア（コンピュータウイルスなどの不正プログラム）を送り込み、情報を盗み出す標的型攻撃が増加しています（図2）。このような攻撃に使用されるマルウェアの多くは、……

>>第1回 第2章の続きを読む（PDFダウンロード）

第2回：認証の基本

前回は、認証の役割と、認証に対する脅威について説明しました。今回は、認証の基本的な考え方と、最も一般的な認証方式である暗証番号やパスワードを使った認証について解説します。

1. 認証のための要素

第1回でも述べたように、認証とは、アクセスしようとしている相手が、間違いなく正式に認められた本人（または機器やサービス）であることを確認するためのステップです。このため認証システムは、アクセスしてきた相手に対して、利用者識別用のIDと同時に、正当性を証明する情報を要求します。この情報を認証要素と呼びます。

例えば、暗証番号やパスワードも認証要素の一つです。これらは、正当な利用者しか知り得ない知識をもとに正当性を確認するものです。一方、電子証明書、スマートカード、ワンタイムパスワード発生機などを利用した認証は、利用者がそれを持っていること（所有）を前提に正当性を確認します。指紋、掌紋、静脈、虹彩（こうさい）などのパターンを利用する生体認証も、同じく所有を前提とします。これらは、人間を対象としているため、より厳密に本人性を確認できます。

しかし、こうした認証要素も完璧ではありません。知識は漏えいや推測によって第三者に渡る可能性があります。また、所有しているものについても、盗難や偽造の可能性がつきまといます。

認証システムは、こうした認証要素を利用して、アクセスを許可するかどうかを決定します。ただし、不正な利用を防ぐため、……

>>第2回 第1章の続きを読む（PDFダウンロード）

2. 暗証番号やパスワードによる認証

知識をもとにした認証で最も普及しているのが、パスワード（パスフレーズ）や暗証番号です。パスワード認証は、ほとんどのシステムやサービスで採用されており、仕事や生活のあらゆる局面で利用されています。パスワード認証の仕組みは、ほとんどのコンピュータOSや開発用フレームワークに標準実装されているため、追加のコストなしで実装できることが普及の大きな理由です。パスワードや暗証番号による認証では、以下の前提で利用者を認証します。

そのため、この前提のいずれかが破れれば、パスワード認証の安全性は損なわれてしまいます。仮に、前提1が崩れた状況を考えてみましょう。

これらは、いずれも典型的な例です。このように、パスワードの秘密性が損なわれてしまうと、認証の安全性が大きく低下します。特に、こうした状況に利用者本人が気付いていない場合、システムを不正利用される危険性が高まります。一方、利用者が気付いた場合は、パスワードを変更することによって、当面の危険回避が可能です。また、定期的にパスワードを変更すれば、気付かなかった場合のリスクも、ある程度は軽減できるでしょう。

しかし、前提2については少し複雑です。パスワードや暗証番号が他人に推測される原因となりうる例を以下に挙げます。

……

>>第2回 第2章の続きを読む（PDFダウンロード）

第3回：パスワード認証へのさまざまな脅威

前回は、認証の基本的な考え方と、暗証番号やパスワードを使った認証を紹介しました。今回は、パスワード認証に対する深刻な脅威と、その対策について解説します。

1. 表玄関からだけではないパスワードへの攻撃

前回紹介した認証機能そのものに対する攻撃は、いわば認証の表玄関に対する脅威です。しかし、認証への脅威はそれだけではありません。どんなにパスワードを複雑に設定しても、システムに保存されているパスワードが盗まれてしまうと、全く意味をなしません。

通常、システムに保存されているパスワードには、外部からアクセスできません。外部どころか、システム内部でも管理者権限がないとアクセスできないのが普通です。しかし、こうした保護をバイパスできる裏口があります。それが脆弱性（ぜいじゃくせい）です。

脆弱性は、本来行われるべき保護が無効になっていたり、回避できたりするシステム上の欠陥（ソフトウェアのバグや設計上の考慮不足など）が原因で発生します。深刻なものでは、それを悪用することで認証を回避してシステムに侵入したり、本来外部からはアクセスできないデータにアクセスできたりします。

一般に、利用者のパスワードは、システム内でファイルやデータベースのかたちで格納され、アクセス制御により一般のアクセスが禁止されています。しかし、脆弱性を悪用することで、外部からのアクセスができてしまいます（図1）。

こうした手段で攻撃者が利用者のパスワードを入手してしまえば、もはやそのログインを防ぐ手立てはありません。このため、万一の漏えいに備えて、……

>>第3回 第1章の続きを読む（PDFダウンロード）

2. パスワードリストによる攻撃

パスワードの流出は、流出元のシステムに被害をもたらすだけとは限りません。とりわけ、インターネット上で提供されているサービスでは、IDにメールアドレスが使われている場合が多く、多数の利用者が、同じメールアドレスとパスワードの組み合わせを、複数のサービスで利用していると考えられます。このため、1つのサービスからIDとパスワードの組み合わせが流出した場合、それを悪用し、他のサービスでも侵害が発生する恐れが生じます。

実際、IDとパスワードの組み合わせリストは闇サイトなどで流通しており、近年それらを使ったリスト型攻撃が多数確認されています。リスト型攻撃では、1つのIDに対して試行は1回のみなので、……

>>第3回 第2章の続きを読む（PDFダウンロード）

第4回：さまざまな認証方式1

前回は、パスワード認証に対する深刻な脅威と、その対策について紹介しました。今回から、パスワード認証以外の主要な認証方式について解説していきます。

1. ワンタイムパスワードによる認証

パスワード認証の大前提の一つに、秘密性、つまりパスワードが他者に漏えいしないことがあります（第2回参照）。しかし、そのためにはさまざまな対応が必要となり、利用者に負担を強いるだけでなく、十分な管理下であっても漏えいのリスクが残ってしまいます。そこで考えられたのが、ワンタイムパスワード（OTP）、いわゆる使い捨てパスワードです。ワンタイムパスワードは、その名のとおり、1回の使用で無効となります。このため、毎回異なるパスワードを使用する必要があり、万一、認証の際にのぞき見や盗聴があっても、それが再利用されることはありません（図1）。

初期のワンタイムパスワードは、システムが作成したパスワードのリストを利用者が保持し、順番に使用していくものでした。利用者とシステムがパスワードのリストを共有することで、認証が可能になります。つまり、ワンタイムパスワードは知識ではなく、リストという所有物を前提とした認証といえます。しかし、保持できるパスワード数には限界があり、多くのパスワードを印刷したリストは保管も大変です。そこで登場したのが、ワンタイムパスワードの発生機（トークンと呼ぶこともあります）です。

利用者は、パスワード認証を行う際、発生機が表示するパスワード（多くの場合は数字列）を入力します。パスワードは、認証のたびに違うものが表示されます。方式によっては、表示されたパスワードが一定時間で無効化されるため、万一、未使用のまま漏えいしても、後で利用できないようになっています。また、リストのように使い切ったあと再発行する必要もなく、有効期限内であれば無制限に使用できるのです。

さて、ここで疑問が生じます。発生するパスワードは、……

>>第4回 第1章の続きを読む（PDFダウンロード）

2. 暗号による認証とスマートカード

暗号技術をより直接的に、認証に使用する方法もあります。現代暗号の基本は、先にも述べたように、伴なしでは復号(同じ結果を導くこと)はできず、暗号列から伴の推測もできないことです。従って、利用者が公式に配布された固有の伴を持っているかどうかをシステム側で検証できれば、認証が成立します。この方法でも、利用者が固有の暗号伴という情報を所有していることを前提に認証を行います。

簡単にいえば、利用者が特定のデータを固有の伴で暗号化してシステムに送り、システムが同じ伴でそれを復号できれば、利用者がその伴を保有していることが確認できます。しかし、それを通信で行うと問題が生じます。同じデータを同じ暗号伴で暗号化した場合、結果は常に同じになります。つまり、暗号化されたデータを盗むことができれば、それを再利用して認証を突破できてしまいます。これをリプレイ攻撃と呼びます。リプレイ攻撃を防ぐためには、毎回、暗号化されたデータが変わるようにしなければなりません。

つまり、伴が同じであれば、暗号化するデータを毎回変える必要があるため、利用者側とシステム側とでどうやってそのデータを共有するかが問題となってきます。それを解決するのが、チャレンジ・レスポンス方式と呼ばれる通信方式です(図5)。

チャレンジ・レスポンス方式では、……

>>第4回 第2章の続きを読む（PDFダウンロード）

第5回：さまざまな認証方式2

前回は、一般的なパスワード以外の認証方式として、ワンタイムパスワードや暗号による認証などを紹介しました。今回も、引き続きさまざまな認証の方式について解説していきましょう。

1. 暗号認証と鍵の保護

前回説明したように、暗号認証では、固有の暗号鍵を所有していることを証明することで、正当性を確認します。このため、固有鍵の保護が重要になります。固有鍵をより強固に保護するには、スマートカードや専用のUSBキーといった、鍵格納用の専用ハードウェアを使用します。これらは、ハードウェアトークンもしくはハードウェアコンテナと呼ばれます（図1）。一方、パスワードを利用した暗号化による鍵保護は、ソフトウェアトークンもしくはソフトウェアコンテナとなります。

こうした専用ハードウェアでは、利用者の固有鍵はチップ内に格納され、外部に取り出すことはできません。ハードウェアにはCPUが搭載され、少量のデータの暗号化や復号などが可能になっています。認証時には、このハードウェアにチャレンジの暗号化を依頼し、結果だけを受け取ってサーバ側に送り返します。これで直接、鍵を使った計算を行うことなく認証ができます（図2）。こうしたハードウェアは、前回述べた耐タンパ性を備えるだけでなく、パスワードによってロックすることもできるため、紛失や盗難に対しても保護されます。

一方、認証サーバ側では、……

>>第5回 第1章の続きを読む（PDFダウンロード）

2. 生体（バイオメトリクス）認証

所有による認証の究極といえるのが、生体認証です。ここまでの認証方式は、人対システムだけでなく、システム同士やさまざまなデバイス、サービスの間でも使用できます。一方、生体認証は、人の認証に特化した方式です。認証要素として利用されるのは、人の身体が持つ、その人固有の特徴です。

最も普及しているのが指紋認証でしょう(図5)。指紋は、犯罪捜査にも使われるように、個人を特定できる身体的特徴の代表格です。同様のものに、掌紋などがあります。ただ、単純な指紋認証では、偽造の危険が伴います。誰かの指紋を採取して偽造することは、比較的容易です。実際、指紋の型を取り、お菓子のグミを利用し偽の指紋を作ることで、指紋認証を突破できてしまうという研究もあります。こうした偽造を防ぐためには、別の手段を使って、それが生きた人間の指であることを確認できなくてはなりません。

より偽造が困難な方法として、皮膚の下にある血管(静脈)のパターンを検知して認証する方法があり、銀行のATMなどで多用されています。それ以外にも、……

>>第5回 第2章の続きを読む（PDFダウンロード）

3. 多要素認証

これまで見てきたように、それぞれの認証方法には固有の利点や弱点があります。とりわけ弱点は、その方式の特性によるところが大きく、無理にカバーしようとすれば、利便性の低下やコストの増大を招く可能性が高くなってしまいます。

そこで、ある認証方式の弱点をカバーするために、特性の異なる別の認証方式を組み合わせて利用するのが、多要素認証です。例えば、最近のオンラインバンキングサイトでは、通常のパスワードに加えて、ワンタイムパスワードを利用することが多くなっています。これは、パスワードの漏洩や推定の弱点をカバーします。一方で、通常のパスワードを併用することで、ワンタイムパスワード発生機の盗難や不正利用に対する保護が可能になります。このように、互いの弱点をカバーするように組み合わせるのが、多要素認証の基本となります。

組み合わせにおいては、第1回で述べた、知識ベースの認証要素と所有ベースの認証要素を組み合わせるものが最も有効です。それぞれの持つ特性が異なるため、互いの弱点をカバーしやすいからです。知識ベースの要素を複数組み合わせた場合、記憶の手間が増えます。一方、所有ベースの組み合わせは、複数の機器を持ち歩くなど、かさばる場合があります。例外があるとすれば、……

>>第5回 第3章の続きを読む（PDFダウンロード）

第6回：補完的な認証方式

前回は、暗号認証や生体認証、多要素認証について解説しました。今回は、主要な認証方式と組み合わせたり、関連する操作の確認などに利用される、補完的な認証方式について解説していきます。

1. 秘密の質問による認証

秘密の質問は、パスワードのリカバリーやリスクベース認証（後述）の確認手段として、よく使用される方法です。あらかじめ決めておいた質問とその回答をセットにして質問を行い、回答が正しいかどうかを確認することで本人性を認証するものです。利用者は、改めて覚える必要のない、記憶として定着している事項で答えられる質問を選択できます。質問も含めて利用者が登録できるものもありますが、多くの場合、システムがあらかじめ用意した選択肢から選びます。これは、利用者が誤って好ましくない質問を設定することを防ぐ意味もあります。

質問から誘導される回答は、秘密性を保証できるものであることが必要です。例えば「電話番号は？」「自動車のナンバーは？」などの質問は、一般に回答の秘密性が低いために、好ましくないといえます。一方、「初めて飼ったペットの名は？」「母の旧姓は？」といった質問は、……

>>第6回 第1章の続きを読む（PDFダウンロード）

2. メール、電話・SMSなどによる確認と承認

IDの新規登録や、重要事項の変更操作などの際に、登録されたメールアドレスに対して確認のメールを送る方法もよく利用されます。これは、なりすましによるID登録や不正アクセスによる変更操作などを、正式な利用者が認識できるようにするためです。メール、電話・SMSによる確認と認証例を紹介します。

多くの場合、メールには承認用のURLが記載されており、そこにアクセスして承認操作を行わないと操作が完了しないようになっています（図1）。

あらかじめ登録された電話番号に、音声やショートメッセージ（SMS）などでコードを送り、それを入力させて確認する方法もよく使用されます。これはメールに比べ、……

>>第6回 第2章の続きを読む（PDFダウンロード）

3. 認証要素のリカバリー

パスワードを忘れたり、カードを紛失したような場合、リカバリーが必要になります。こうしたリカバリーでは、認証要素そのものを再設定する必要があります。この操作は旧来、システム管理者が利用者から依頼を受け、本人確認を行ってから実行していました。しかし、近年では管理者の負荷を減らすために、リカバリーをセルフサービスで行えるようにすることが多くなっています。

パスワードを忘れた際の再設定、カードやワンタイムパスワード発生機などを紛失した場合の無効化や、再発行時の利用登録といった操作を利用者自身が行う場合、それが正当な利用者であるかを確認、認証する方法が問題となります。この場合、本来の認証方法は使えないため、なんらかの代替手段が必要となります。

最もよく使われている方法が、図1のメールを使う方法です。パスワードの再設定を要求する際、まず登録済みのメールアドレスの入力を促します。入力されたメールアドレスが登録済みのものと一致すれば、そのアドレスにメールを送ります。もし一致しなかった場合でも、特にエラーを出したりはしません。これは、入力を繰り返してメールアドレスを特定されるのを防ぐためです。送られたメールには、パスワード再設定用のURLが記載されており、利用者はそこにアクセスしてパスワードを再設定します。ここでは、利用者側でメールの秘密が保たれていることを前提としています。近年、メールサーバ間での通信が暗号化されることも多くなり、メールの盗聴の可能性は低くなりました。しかし、……

>>第6回 第3章の続きを読む（PDFダウンロード）

4. リスクベース認証と行動パターン認証

認証が成功した場合でも、それが本来の利用者でない、なりすましの可能性を計算し、それが高ければ自動的に追加認証を要求するなどの対処を行うことがあります。これを、リスクベース認証といいます。クレジットカード会社の多くでは、カード使用の時間間隔と使用された地域の間の距離をもとに、移動が困難と思われる時間での利用についてチェックを行っています。こうしたチェックは、システムの認証においても可能です。リスクベースの認証システムでは、認証を行った相手のさまざまな属性を利用してこれを行います(図3)。使われる属性としては、

・クライアントのIPアドレス

IPアドレスの割り当て地域やISPなどの情報をもとに、地理的な隔たりの大きな利用や、普段と異なる国などでの利用をチェック

・クライアントの利用環境

Webベースの認証の場合、アクセス時のブラウザ情報(User Agent情報)や利用しているアプリケーション情報を調べ、普段と異なるブラウザやアプリケーション、OS環境からの利用をチェック

・クライアントのアクセス時刻

クライアントが認証システムにアクセスする時刻が、普段と大きく違っていないかをチェック

といったものが考えられます。もちろん、たまたま利用者がそのようなアクセスを行った可能性もあり、こうしたチェックは、あくまで目安に過ぎません。そこで、利用者をより厳密に確認するために、……

>>第6回 第4章の続きを読む（PDFダウンロード）

第7回：シングル・サインオンとフェデレーション

前回は、主要な認証方式と組み合わせて使う補完的な認証方式について解説しました。今回は、1回の認証で複数のシステムへのアクセスを可能とするシングル・サインオンと、管理運営主体の異なるサービス間でIDや認証の相互連携を行うフェデレーションについて解説します。

1. シングル・サインオンとその仕組み

企業などの組織では、さまざまなシステムが稼働しています。これらは、全てが同時に稼働し始めたものではなく、後に必要に応じて追加されたものも少なくありません。重要な情報を扱う企業システムでは、確実なID管理や認証とアクセス制御が必要なのは当然のことです。しかし、これらの仕組みをシステムごとに実装していては管理が繁雑化する上、システムごとにログインが必要になるなど、使う側にとっても不便が生じます。とりわけ近年、ビジネス環境の変化が激しくなるにつれ、情報システムは環境への迅速な対応を迫られており、新たなシステムの追加や変更が頻繁に行われるようになっています。このような状況で、ID管理や認証を個別に行っていたのでは、システムの運用が成り立たなくなってしまいます。

こうした問題を解決するための方策が、シングル・サインオンによるID管理と認証の一本化です。シングル・サインオン環境では、利用者は認証を1回受けるだけで、自由にシステム間を移動できます。システムは、それ自身が認証やID管理を行うのではなく、シングル・サインオンを提供する認証システムと連携して、ユーザーのアクセスを許可します。シングル・サインオンの流れを、図1に示します。

ユーザーが各システムにアクセスすると、システムはユーザーをいったん認証システムに送り、そこで認証を受けさせます。認証が完了すると、ユーザーは認証済みとしてシステムに戻され、システムではそのIDに決められた権限を与え、アクセスを許可します。認証システムは、送られたユーザーが認証済みかどうかを判断し、認証済みでなければ改めて認証画面を表示し、認証を受けさせます。このような仕組みにより、ユーザーはログアウトするか、一定時間を経過するまで、複数のシステムを自由に行き来できることになります。

旧来のクライアント・サーバ型のシステムでは、こうしたシングル・サインオンの実現には、使用する認証システム製品（シングル・サインオン製品）に固有のプラグインなどが必要となり、製品への依存が強くなりがちでした。一方、近年主流となっているWebアプリケーション主体のシステムでは、……

>>第7回 第1章の続きを読む（PDFダウンロード）

2. ID・認証連携（フェデレーション）とクラウド

さて、企業システム(いわゆるオン・プレミスのシステム)から、クラウドサービスへシングル・サインオンを拡大することは、運営主体が異なるサービス間で認証の連携を行うことになります。このため、こうした異なる主体間での信頼関係を、どのように保つのかという問題が生じます。当然、企業側ではクラウドサービス全般のセキュリティリスクを考慮する必要があります。ことID・認証管理に関していえば、サービス事業者側にも、外部のID管理や認証結果を受け入れることによるリスクが生じます。こうした事業者側のリスクは、複数の利用者(企業ユーザー=テナント)がサービス基盤を供用する(これを、マルチテナントと呼びます)という特性上、全利用者に拡散しかねません。もちろん、マルチテナントのシステムでは、各利用者のユーザー管理やパスワードなどの認証要素に対する管理責任は、多くの場合、利用者側にあります。このため、クラウド事業者は、利用者側の管理上の不備から生じるリスクが、他の利用者や事業者自身の管理システム、サービス基盤に波及しないよう、各利用者のシステム環境を論理的に隔離する処置を講じています。利用者側の認証結果の受け入れは、そのような隔離を前提で成り立っているのです。

このように、他者のID・認証管理を受け入れる考え方を、より拡大したのがID・認証連携(フェデレーション)です(図3)。異なる企業や事業者が、相互に相手のIDや認証結果を受け入れることができれば、利用者の利便性は一気に高まります。もちろん、このためには、先に述べたような利用者環境の隔離に加え、相手事業者や企業のID管理や認証のセキュリティが、自社の要求を満たしていることが必要です。

企業同士のフェデレーションには、例えばグループ企業間、取引先、合併時などにおける、システム機能の相互または一方的な利用が必要とされるときに、ID管理や認証の統合なしに利用できるというメリットがあります。企業間のフェデレーションでは、ビジネス上重要な情報を扱うことが多いため、……

>>第7回 第2章の続きを読む（PDFダウンロード）

第8回：認証システムの運用と管理

前回は、シングル・サインオンとフェデレーションについて解説しました。最終回となる今回は、これまで述べてきたような認証システムを、運用・管理していく上での留意点をいくつか紹介しましょう。

1. ID管理の重要性

利用者IDの管理と認証の管理は、密接な関係にあります。IDを付与する、つまり利用者にサービスアカウントを与えることは、利用者に対してそのサービスの利用を認めるということです。それが企業のビジネスシステムである場合、こうした利用者の管理は、人事などとも密接に関係してきます。このため、ID管理業務のプロセスは、一般に社内規程に従って定められることになります。企業は社員に対し、業務上必要なアカウントを作成し、IDを付与して、必要な情報や機能にのみ、アクセスを許可します。

また、特に人事異動に伴うアカウントやその権限の変更は、確実に行われる必要があります。不要になったアカウントや権限を放置すれば、思わぬ事故につながりかねません。とりわけ、退職者のアカウントは……

>>第8回 第1章の続きを読む（PDFダウンロード）

2. パスワードに関する管理

パスワードなどの認証要素の管理は、基本的には利用者の責任です。このため、適切なパスワード設定の基準や、取り扱い上の注意（付箋に書いて貼らない、などの基本的な事項）は、分かりやすい形で利用者に周知し、理解してもらう必要があります。一方、パスワードの複雑性（文字数や文字種など）については、基準を満たさないものを受け付けないよう、システム側でチェックできます。WindowsなどのOSでは、パスワードポリシーを強制する機能（標準装備）を利用することで、脆弱（ぜいじゃく）なパスワードの使用をある程度防止できます。また、変更頻度についても同様で、定期的な変更をシステムで強制することもできます。

ただ、パスワード認証の項目（第2回）で解説したように、過度な強制が問題となることもあります。長すぎるパスワードの要求は、単純な単語の繰り返しなど、むしろ脆弱なパスワードの使用を招く危険があります。頻繁な変更要求に、単純な文字や順序の入れ替えなど安直な方法をとる可能性もあります（図2）。

このようなパスワードは、せっかくのパスワードポリシーを台無しにしてしまいます。また、こうした安直な変更を全てシステムでチェックすることは、非常に困難です。

一方、8文字程度のパスワードでも、適切に作れば、……

>>第8回 第2章の続きを読む（PDFダウンロード）

3. 認証システムのログ

認証システムを運用する際に重要なのが、ログの管理です。認証の成功や失敗は、確実に記録しておくことが求められます。失敗だけでなく、成功の記録も必要とされるのは、誰がいつシステムにログインしたかという情報が、非常に重要だからです。何らかの理由でシステム利用状況の追跡が必要になった場合、特定のIDによるログイン状況を集計できれば、それが可能になります。情報システム利用状況の把握は、IT部門にとって重要な業務のひとつですから、その集計・分析に認証ログが役立ちます。

セキュリティの観点からいえば、システムの利用状況から不正の兆候を見いだせる可能性もあります。業務時間外、とりわけ深夜や休日のアクセス、リモートアクセスは、監視の目が届きにくく、不正の温床となる可能性や、労務管理上の問題が発生する場合も考えられます。このため、認証ログの定期的な集計とチェックには、大きな意味があります。Windowsでは、認証成功ログの取得は、標準では無効となっているため、特に重要なサーバ、例えばドメインコントローラやファイルサーバなどでは、有効にしておくことを推奨します(変更は、ローカルセキュリティポリシーやグループポリシーの監査設定で行います)。

一方、認証失敗ログのチェックでは、……

>>第8回 第3章の続きを読む（PDFダウンロード）

4. 認証ログとセキュリティインシデントへの対応

前述のように、認証システムのログは、不正や攻撃を発見する手がかりとなります。一方で、情報の漏えいや、システム内部でマルウエアの感染が発見されるなど、セキュリティインシデント(事故)が発生する場合があります。このとき、認証ログを確認・精査することによって、異常なログインや、管理者アカウントなどへの不正なアクセスが発見できれば、インシデントの原因を解明するきっかけとなります。

このため、セキュリティインシデントが発生した場合、関連が疑われるシステムのログは、できるだけ速やかに保全する必要があります。破壊されないまでも、容量確保のためのローテーションなどで消されてしまう可能性があるからです。とりわけ、多くの利用者がいるインターネット公開サービスでは、ログの保存期間が短くなりがちです。保全のタイミングが遅れれば、大きな手がかりが失われてしまうことになります。

また近年、政府機関、重要インフラ、基幹産業などをピンポイントで狙った、いわゆる標的型攻撃が……

>>第8回 第4章の続きを読む（PDFダウンロード）