認証（IA）とアクセス制御（AC）/追跡（AU）

前回はNIST Cyber Security Frameworkにおける「特定」を司る、リスクアセスメント（RA）と内部監査（CA）を解説した。本記事では、「防御」を司る、認証（IA）、アクセス制御（AC）、追跡（AU）の3ファミリーについて解説する。CSFにおける防御とは、如何に侵入されないかということについて着目したステップであり、前回のリスクアセスメント（RA）で解説した脆弱性評価と対策は、まさに防御に分類される。

本記事では脆弱性へのアプローチの中でも、パッチを適応するなどの局所的な対応ではなく、攻撃者の侵入を体系的に防御するための仕組みづくりに近い領域を解説する。また、この3つの領域はゼロトラストを実施する際の基礎となるファミリーであるため、その点に関しても簡単に触れることとする。

本格的なサイバー攻撃を成立させるにあたって、避けて通れないステップは「認証の突破」である。攻撃者はメガブリーチと呼ばれる、数万件単位のIDとパスワードの組み合わせの漏洩情報などを購入したり、フィッシングサイトなどに対象をおびき出して偽のログインパネルなどに認証情報を入力させる。場合によってはキーロガーと呼ばれる、キーボードへの入力情報を搾取し、攻撃者のもとに送信し続けるマルウェアに感染させるなど、巧妙なものもある。執筆時点でかなり世間を騒がせているネット証券口座への不正ログインなども同様の手口である。更にレベルの高い攻撃者になれば、Entra ID（旧 Active Directory）のKerberos Ticketの有効期限や権限を書き換えたTGT（Ticket Granting Ticket）を発行し、認証を突破したりする。

ここでは書ききれないほどに数多の手法を用いて認証を突破し、そこからようやく攻撃者は目的達成に向けて動き出すのである。つまり、認証を突破されないことというのはCSFにおける防御の観点から、極めて重要なことであると言える。

実際にどのような方法で認証の防御を固めるのかといえば、識別子や認証子の管理にほかならない。識別子とは、アカウントテーブルにおけるIDの管理だと言い換えてもよい。例えば筆者であれば「motoki.nishio」や「m.nishio」などが識別子となることが多い。私の場合にはなかなか同名の人物と遭遇することはないが、同じ組織内で重複が発生する確率はそれなりにあるのである。例えば韓国や中国では一つのシステムの中に名前が重複する人物が10名以上いることなど珍しくはないらしい。その場合IDの最後に数字をつけるなどして、固有の人物を特定できるように管理することが必要である。

ここまでであれば至極普通のことを言っているように見えるが、意外にも中小企業か大企業かを問わず、「使いまわしアカウント」というのが存在している。これは識別という概念を根底から破壊する最も愚かな行為なのである。使いまわしアカウントの危険性として挙げられるのは、権限集中と追跡性の消失である。使いまわしアカウントは複数の人物が複数の業務をするために複数の権限が集中していることが多く、一度アカウントが乗っ取られれば多大なる影響が出るのである（アクセス制御の章でも触れる）。

また、追跡性の消失とはその字の通りで、きちんとした識別子を持って運用されている組織においてなにかインシデントが発生した場合には、誰のアカウントが乗っ取られたかを軸に、侵入経路の分析や、乗っ取られたアカウントの権限の総和から被害範囲の暫定的な把握ができるが、使いまわしアカウントを乗っ取られた場合にはこれらは困難を極める。使いまわしアカウントが識別に与える負の影響を十分に理解していただきたい。

次に、認証子とは、認証を試みているユーザーが、想定される本人であるか否かを識別するための要素である。主に「知識情報」「所持情報」「生体情報」が認証子となり得る。最も簡単な例はIDとパスワードの組み合わせによる「知識情報」の確認である。ただし、単一の認証子による確認では昨今のサイバー攻撃には抗えない。例えばPCやスマートフォンに端末証明書をインストールすることで、確かに本人の持ち物である端末からアクセスされているということを示す「所持情報」や、指紋や顔などの「生体情報」を認証条件に加えることで飛躍的に認証を突破される可能性を低減できる。

攻撃者が漏洩したIDとパスワードのみを持って認証を突破しようとする場合、多要素認証が実装されていれば、攻撃者は端末を乗っ取ったり、生体情報を盗む必要が生まれ、極端に攻撃コストが肥大化することになる。多要素認証では、前述した「知識情報」「所持情報」「生体情報」から2つ以上を組み合わせることを条件としている。最も一般的な多要素認証は、IDとパスワードの組み合わせ（知識情報）＋事前に登録した電話番号やメールアドレスへワンタイムパスワードを送付して入力させる（所持情報）の組み合わせだろう。

ただし、この多要素認証すらも突破されるのが現代のサイバー攻撃の巧妙さなのである。だからこそ、多要素認証の導入は必須と言って全く過言ではない。

認証が突破された、もしくは認証後のユーザーが何らかの方法でその制御を乗っ取られたとした場合に、次なる防御壁となるのがアクセス制御である。

前章でも触れたが、使いまわしアカウントのような、極めて強力な権限を有したユーザーが存在し、それが乗っ取られれば、甚大な被害をもたらす。また、そのような個人が特定できない高権限なユーザーの存在は内部犯行をも誘発するのである。

そのため、ユーザーへのアクセス権限の付与は、最小限に留めることが求められる。高権限なユーザーが1つ存在していて、そのユーザーが乗っ取られないように守るというのは、現代のサイバー攻撃を甘く見積もりすぎている戦略と言える。そうではなくて、業務や部門などによって細かく権限管理をし、それらに合わせた最小のユーザーアカウントが存在していることの方が、乗っ取られることを前提とした現代のサイバー攻撃対策として有能であるということである。

このような権限管理と最小権限の原則を適応するには、当然であるが自社のITシステムがバリューチェーンや情報の重要度など何らかの基準によりエリア分けされている必要がある。そうでなければいくらアカウントテーブル上で権限管理をしたところで、制御が追いつかないということになる。

NIST SP800-53では前述の制御をネットワークセグメントで実施することを推奨している。初版発行は2005年であるが、今から思えば現代のゼロトラストの基礎を築く考え方である。AC-4では「Authorization Boundary（認可境界）」なる概念が出現する。一度でもNIST対応を実施したことがある人は、二度と聞きたくないと思っている概念かもしれない。細かく説明しようと思えば本が一冊出版できてしまうが、NISTにおける認可境界とは、大まかに言えば以下「セグメントの分割方法」と「セグメントに含めるべきシステムの範囲」の2つが主要素となる。

セグメントの分割方法において強く推奨されているのが「VLANなどを用いたネットワークセグメントの利用」である。アクセステーブル上での論理的制御のみだと、より高権限のユーザーの乗っ取りなどのアカウントテーブルの侵害に対応しきれないからだ（詳細な説明は割愛する）。

また、「セグメントに含めるべきシステムの範囲」について考えるにあたっては、SP800-53が情報保護のためのフレームワークであることを起点に考えればよい。

つまり、前回の記事に記載した通り、リスクマネジメントを実施する際に定義した守るべき対象情報を保有しているか否かで、認可境界内に含めるべきかどうかを判断すればよいということだ。

ただし、ここが認可境界最大のミソなのだが、守るべき対象情報を保有していないシステムであっても認可境界に含めなければならない条件がある。ものすごく簡単に説明すれば「“守るべき対象情報を保有するシステム“を攻撃するために足がかりとなるシステム」ということになる。

認証、アクセス制御の型が固まれば、それらが適切に運用されているかのログを取得する必要がある。前回の記事でも触れたが、現代のサイバー攻撃は、攻撃されること、認証やアクセス制御が突破されることを前提にする必要があり、だからこそログの取得をはじめとするガバナンスが非常に重要なのである。

最近では取得したログをリアルタイムで横断分析して、組織内で何が起きているのかを即座に可視化できるSecurity Information and Event Management（SIEM）製品なども発達してきた。

このようにログの取得とは認証前後の記録を取り、検証することで、「一連の行動の怪しさ」を定義することに使用される極めて重要なインプットなのである。攻撃者からすれば、厄介極まりない存在である。

そのため、ログを取得し、活用する際には、ログ自体のバックアップや保護を忘れてはいけない。例えば取得したログファイルを一定間隔で外部のログ保管用のファイルサーバーなどに転送するなどが求められる。一流の攻撃者であればあるほど、ログファイルの扱いが上手いのである。ログファイルを削除するだけならまだしも、巧妙に改ざんするなどし、インシデントレスポンスを妨害/ミスリードする。ログの取得と保護は、CSFにおける全てのフェーズにおいて活用できる基礎中の基礎と言える。

本記事で紹介した「認証（IA）」「アクセス制御（AC）」「追跡（AU）」はまさにゼロトラストの礎である。前回の記事ですでにゼロトラストについてはある程度解説している。

ゼロトラストでは、認証時の本人確認の厳格化に加え、あらゆるログを精査し、認証後の動きを追跡しながら「怪しさ」を図り、それに合わせて動的にアクセス制御の認可とネットワークの動的な制御を行うことなのである。

つまり本記事に記載されている要素を理解しないままゼロトラストを導入しても使いこなせるはずがないということである。しかし逆説的に言えば、ここに記したことを一つ一つ手で実装するよりは、一足飛びにゼロトラスト基盤に乗ってしまうというのもありなのである。中でも中小企業であれば前述のSASEとSaaSの組み合わせで十分に実装することができるだろう。