サイバー攻撃を受けた場合、ブランドの毀損・風評被害、顧客への賠償、管轄当局からの指導（規制産業の場合）・罰金などがあると言われるが、日本の場合、罰金が本当にあるのか疑問に思ったので調べてみた。
米国では、SECの規則などもあり、サイバー攻撃を受けた会社に対して罰金がかかることがある。一方で、日本では、個人情報保護法に基づくものしか見つからなかった。ただ、個人情報保護法に関するものといっても、従業員等が持ち出した場合については明確だが、サイバー攻撃を受けて持ち出された場合に適用されるかは不明確で、罰金を受けないかもしれない。
「ゼロトラスト製品」という言葉を聞くと、どれでもゼロトラストを実現できそうな気がするが、そうではないらしい。
「ゼロトラストとはなにか」を正しく理解していないと、ゼロトラスト製品をいれてもゼロトラスト化できませんということになる。
「ゼロトラストとは何であって、何でないか」の背景情報を正しく捉えていないと、誤った結論に行き着いてしまう。背景情報の違いによって、誤判断する例を見つけたのでメモ。
出典: https://www.psy.ritsumei.ac.jp/akitaoka/light2.html
（https://www.ritsumei.ac.jp/~akitaoka/）
ファイアウォールのアクセスコントロールリスト（ACL）でアクセス制御を行っているネットワークにおいては、正規ユーザも攻撃者もIPアドレスを指定することで、存在する機器の探索、アクセスしたい機器への接続が可能になる。
アクセスの可否を厳格にコントロールするためには、「だれが（ユーザの特定）」「どこに（アクセス先の特定）」アクセスしてよいのかを厳格に設定する必要があるが、IPアドレスとポート番号に基づくアクセス制御であるACLでは限界がある。
近年のファイアウォールでの制御方法
ファイアウォールでの通信可否判断の基本形は、通信の発信元と宛先それぞれのIPアドレスとポート番号で制御を行うことである。
発信元・宛先のIPアドレスを1件ずつ登録すると、制御のルールが膨大になってしまうため、発信元もしくは宛先の少なくとも片方は、ネットワーク単位で指定することがほとんどである。例えば、発信元は従業員フロア全体のIPアドレス帯（IPアドレスレンジ）、宛先はイントラネットサーバのIPアドレスという感じである。
また、ポート番号は、発信元はすべてのポート番号（任意の番号という意味でANYとよばれる）として、宛先のポート番号をアプリケーション（例:Webサーバであれば80番・443番、メールサーバであれば25番など）に合わせて設定を行う。
ポート番号の指定の際、TCPとUDPのどちらの通信プロトコルを使うかも合わせて指定するため、例えば、80/tcpや443/tcpなどの表現になる。
そして、これらのアクセス制御ルールをまとめたものは、アクセスコントロールリスト（ACL）と呼ばれている。
2000年代初期ごろまではACLでの制御で十分であったが、仮想サーバ技術やクラウド環境などの新技術により、ACLだけではアクセス制御が難しくなっている。特に、ゼロトラストに必要な「だれが（ユーザの特定）」「どこに（アクセス先の特定）」の特定をACLでは実現できない問題がある。
そこで、近年のファイアウォールの新機能として、
などの改善が行われており、可否判断の精度・粒度が向上している。しかし、これらの補完的な機能は「補完的」でしかなく、これらのみを使った通信可否判断はできない。
例えば、項目1については、自社開発のアプリケーションや、あまりメジャーでは無いアプリケーションは、アプリケーション識別のデータベースには含まれないため、従来の宛先IPアドレス・宛先ポート番号に基づく通信可否判断が必要である。アプリケーションの識別情報を自分で登録することが可能であったとしても、自社で利用しているすべてのアプリケーションについて識別情報を見極めていくのは時間的、スキル的、金銭的に困難であろうことから、実運用を考えると現実的な選択肢とは言い難い。
また、項目2については、ユーザがMicrosoft AD（アクティブディレクトリ）でのドメイン認証や、VPNサーバへの接続時の認証など、認証サーバでの認証を受けてくれた場合は通信の発信元IPアドレスとユーザ名を紐づけるログが発生するため、ユーザ単位での通信可否判断が可能になる。しかし、PC内のローカルアカウントでログオンした場合など、認証サーバでの認証が行われないケースでは紐づけができないため、通信の発信元IPアドレスでの通信可否判断が必要になる。
IPアドレスとユーザ名の紐づけができない別のケースとして、シンクライアント端末がある。1つのサーバの上に複数の仮想PCが動いており、通信が同じIPアドレスから発信されるケースでは、IPアドレスからユーザ名を検索することができないため、ユーザ名でのアクセス制御を行うことができない。シンクライアント端末以外にも、Microsoftターミナルサーバに複数ユーザがログインしているケースも同様である。
繰り返しになるが、ゼロトラスト化においては、誰が、何にアクセスしてよいのかを厳格に判断し、ポリシーに沿って制御を行っていく必要があるが、ファイアウォールではその判断が不十分になりやすい、もしくは、厳格にするために人・金・時間を追加投資する必要があることから、ファイアウォールでは、ゼロトラスト化を実現することは困難だと言える。
すでに、ファイアウォールでは宛先をIPアドレスで指定する必要があることを説明したが、ここではIPアドレスで指定することの問題点を解説する。
まず、近年はサーバ自体の性能が向上しており、1つのサーバの上で複数のアプリケーションが動かされている。例えば、1つのWebサーバに複数のサーバ名を持たせ、アクセスする際に使用したURLで表示するアプリケーションを分けていることがある。具体的な例は、https://finance.local.corp、https://intra.local.corp、https://hr.local.corp、など異なるURLであるが、実際には1つのWebサーバ（以下、サーバA＝10.1.64.1）上に存在するケースである。
この場合、宛先IPアドレスはサーバAのものになり、ファイアウォールのルールで記述すると以下のようになる。なお、従業員PCは10.0.0.0/16のネットワークのどこかに設置されるものとする。
発信元IP | 発信元ポート | 宛先IP | 宛先ポート | アクション |
10.0.0.0/16 | Any | 10.1.64.1 | 443/tcp | Permit |
このルールで「Any」はすべての値を受け付けるという意味であり、発信元は従業員PCの設置されたネットワークであればどこからでもよいが、宛先はIPアドレスが10.1.64.1、ポート番号が443/tcpの通信を許可するという意味である。このルールにより、全従業員が3つ全てのアプリケーションにアクセスできるようになる。
しかし、https://finance.local.corpとhttps://hr.local.corpは、それぞれ、経理部門と人事部門の従業員のみにアクセスさせるという要件が出てくると、途端に困難に直面する。そもそも、ゼロトラストの原則により、誰が、どこにアクセスできるのかを厳格に制御する必要があるため、これは当然発生する要件である。
アクセス可否を表にまとめると以下のようになる。
| finance.local.corp | intra.local.corp | hr.local.corp | その他 |
経理部門 | 可 | 可 | 禁止 | 禁止 |
人事部門 | 禁止 | 可 | 可 | 禁止 |
その他部門 | 禁止 | 可 | 禁止 | 禁止 |
ファイアウォールの新機能の一つとして紹介した、前述のユーザ単位での制御により対応をする場合は、https://intra.local.corpへの全員アクセス許可、それ以外のサイトへのアクセスは全員禁止のルールに加えて、以下のようなファイアウォールのルールが作れればよい。
発信元IP | ユーザ名 | 発信元ポート | 宛先IP | 宛先ポート | アクション |
| Finance-group | Any | finance.local.corp | 443/tcp | Permit |
|
HR-group |
Any |
hr.local.corp |
443/tcp |
Permit |
10.0.0.0/16 |
（全従業員） |
Any |
intra.local.corp |
443/tcp |
Permit |
10.0.0.0/16 |
（全従業員） |
Any |
Any |
Any |
Block |
しかし実際には、上表をそのままファイアウォールに実装することはできない。まず、経理部門と人事部門を表すFinance-groupとHR-groupに含まれるべきユーザの一覧が必要になる。Microsoft ADやLDAPサーバからグループ情報を取り込めるファイアウォールであればよいが、取り込めない場合は1ユーザずつ登録が必要になる。
発信元IP | ユーザ名 | 発信元ポート | 宛先IP | 宛先ポート | アクション |
| Finance-User-1 Finance-User-2 | Any | finance.local.corp | 443/tcp | Permit |
| HR-User-1 HR-User-2 | Any | hr.local.corp | 443/tcp | Permit |
10.0.0.0/16 | （全従業員） | Any | intra.local.corp | 443/tcp | Permit |
10.0.0.0/16 | （全従業員） | Any | Any | Any | Block |
加えて、ユーザ名がわかったとして、ファイアウォールはIPアドレスとポート番号で通信を制御する機械であるため、発信元IPアドレスが必要である。
発信元IP | ユーザ名 | 発信元ポート | 宛先IP | 宛先ポート | アクション |
10.0.0.0/16 | Finance-User-1 Finance-User-2 | Any | finance.local.corp | 443/tcp | Permit |
10.0.0.0/16 | HR-User-1 HR-User-2 | Any | hr.local.corp | 443/tcp | Permit |
10.0.0.0/16 | （全従業員） | Any | intra.local.corp | 443/tcp | Permit |
10.0.0.0/16 | （全従業員） | Any | Any | Any | Block |
しかし、この発信元IPアドレスレンジには、他の従業員も含まれ、中にはIPアドレスとユーザ名が紐づけられていないケースがある。セキュリティを優先すると、そのような紐づけされていないユーザはアクセスを禁止する対応になるが、利便性は低下する。もしくは、PCごとにIPアドレスを固定する対応であるが、それはそれで管理が大変になる。（社内の全端末を固定IP化してもよいが膨大な管理コストがかかる。一部の端末のみ固定IP化する場合、端末の入れ替え時に割り振られるべ固定IPが割り振られない。当該固定IPを他の従業員が手動で設定すると、本来禁止すべき通信が許可される。など）
発信元IP | ユーザ名 | 発信元ポート | 宛先IP | 宛先ポート | アクション |
10.0.0.0/16 | Finance-User-1 Finance-User-2 上記以外は禁止 | Any | finance.local.corp | 443/tcp | Permit |
10.0.0.0/16 | HR-User-1 HR-User-2 上記以外は禁止 | Any | hr.local.corp | 443/tcp | Permit |
10.0.0.0/16 | （全従業員） | Any | intra.local.corp | 443/tcp | Permit |
10.0.0.0/16 | （全従業員） | Any | Any | Any | Block |
続いて宛先についてだが、サーバ名のままではファイアウォールは通信の処理ができないため、IPアドレスに変換する（以下、名前解決）必要がある。
発信元IP | ユーザ名 | 発信元ポート | 宛先IP | 宛先ポート | アクション |
10.0.0.0/16 | Finance-User-1 Finance-User-2 上記以外は禁止 | Any | 10.1.64.1 | 443/tcp | Permit |
10.0.0.0/16 | HR-User-1 HR-User-2 上記以外は禁止 | Any | 10.1.64.1 | 443/tcp | Permit |
10.0.0.0/16 | （全従業員） | Any | 10.1.64.1 | 443/tcp | Permit |
10.0.0.0/16 | （全従業員） | Any | Any | Any | Block |
ファイアウォール自身がサーバ名をIPアドレスに名前解決してくれるようなファイアウォールであればよいが、人手で変換が必要な場合、運用負荷が高まる。例えば、サーバが老朽化した際の更新時、アプリケーションのバージョンアップ時の並行稼働時、データセンタ移行時、などサーバ名に割り当てられるIPアドレスが変化する状況が発生する。その際、毎回ファイアウォールのルールの書き換えが必要になる。
加えて、ファイアウォール自身が名前解決をする場合であっても、IPアドレスが動的に変わる場合は、アクセス毎にIPアドレスが変化するため、ファイアウォールでは対応できない。IPアドレスが動的に変わる例としては、SaaSサービスの利用時やパブリッククラウドのリージョンが切り替わるケース、本番環境と災害対策環境の切り替え時（もしくは、Active-Activeで稼働させ、通信遅延の少ない方に自動的に接続させる場合）などがある。
また、データセンタごとに異なるIPアドレスを返すDNSサーバがある場合も注意が必要である。ファイアウォールの設定を一括管理している場合、管理サーバ・管理コンソールが名前解決を行った際に取得されたIPアドレスが各ファイアウォールに配布される。ファイアウォールの設置場所ごとに異なるIPアドレスが必要な場合、通信が意図せず、許可・ブロックされる場合がある。例えば、本番環境に設置されたファイアウォールは本番環境のサーバに、災害対策環境に設置されたファイアウォールは災害対策環境のサーバに通信すべきであるところ、管理サーバの名前解決では本番環境のIPアドレスしか取得できない場合、災害対策環境のサーバへの通信はブロックされることになる。この点についても手動で対策が必要になってくる。
ここでは、リージョンが切り替わり、IPアドレスが一定の範囲内で変化するケースを例にする。その場合、宛先IPアドレスは各リージョンのIPアドレス帯全体を指すことになる。
発信元IP | ユーザ名 | 発信元ポート | 宛先IP | 宛先ポート | アクション |
10.0.0.0/16 | Finance-User-1 Finance-User-2 上記以外は禁止 | Any |
10.1.64.0/24（リージョン1） 10.1.65.0/24（リージョン2） | 443/tcp | Permit |
10.0.0.0/16 | HR-User-1 HR-User-2 上記以外は禁止 | Any |
10.1.64.0/24（リージョン1） 10.1.65.0/24（リージョン2） | 443/tcp | Permit |
10.0.0.0/16 | （全従業員） | Any |
10.1.64.0/24（リージョン1） 10.1.65.0/24（リージョン2） | 443/tcp | Permit |
10.0.0.0/16 | （全従業員） | Any | Any | Any | Block |
このようなルールになった場合、経理部門・人事部門の従業員は、パブリッククラウドのリージョン1・2のサーバのどこにでもアクセスできることになる。
通信の特徴を掴んで、アプリケーションを識別する機能が使えるケースであれば、経理部門・人事部門がアクセスできるアプリケーションをそれぞれ用のアプリケーションに限定することが可能であるが、有名どころのアプリケーションでなければ対応しておらず、この機能は使えない。
その結果、経理部門・人事部門は互いに相手用のアプリケーションにアクセスできてしまう。この組織のサーバがすべてパブリッククラウドにあるとした場合の、アクセス可否表は以下のようになる。
| finance.local.corp | intra.local.corp | hr.local.corp | その他 |
|
経理部門（IPに紐づけ可） | 可 | 可 | 禁止→可 | 禁止→可 |
|
経理部門（IPに紐づけ不可） | 設定なし→禁止 | 設定なし→可 | 設定なし→禁止 | 設定なし→禁止 | 想定外のケース |
人事部門（IPに紐づけ可） | 禁止→可 | 可 | 可 | 禁止→可 |
|
人事部門（IPに紐づけ不可） | 設定なし→禁止 | 設定なし→可 | 設定なし→禁止 | 設定なし→禁止 | 想定外のケース |
その他部門 | 禁止 | 可 | 禁止 | 禁止 |
|
実際に設定される表は、当初想定したアクセス制御の内容とは異なっており、ファイアウォールでは「誰が」と「どこに」を厳格に適用できていないことが分かる。
アクセスの可否を厳格にコントロールするためには、「だれが（ユーザの特定）」「どこに（アクセス先の特定）」アクセスしてよいのかを厳格に設定する必要があるが、ユーザおよびサーバをIPアドレスで識別するファイアウォールでは識別に限界があり、ゼロトラストを実装することができない。
この問題に対応するには、シンプルに、ユーザおよびサーバをIPアドレスではなく、ユーザIDとサーバのURLで判断すれば良い。そうすることで、ゼロトラストを導入できることに加え、アクセス制御の管理もシンプルになる。
発信元IP | ユーザ名 | 発信元ポート | 宛先IP | 宛先ポート | アクション |
| Finance-group | Any | finance.local.corp | 443/tcp | Permit |
| HR-group | Any | hr.local.corp | 443/tcp | Permit |
| （全従業員） | Any | intra.local.corp | 443/tcp | Permit |
| （全従業員） | Any | Any | Any | Block |
