インターネットの普及により、日本でもインターネットを活用した選挙運動が解禁されていますが、記事作成時点では公職選挙法においてインターネットによる投票は認められていません。日本でも導入について議論されているインターネット投票ですが、世界の一部の国ではインターネット投票が既に実施されています。
ヨーロッパの小国であるエストニアでは、国政選挙においてインターネット投票が採用されています。しかし、セキュリティの専門家は長らく「インターネット投票の安全性は低く、それを安全にできる技術は未だ存在せず、将来的にも存在しない」と主張してきました。
それでもインターネット投票システムを提供するベンダーは存在しており、「自社の新しいシステムは従来とは異なる」や「安全性の低さは問題ではない」と主張し続けています。こういった主張は誤解を招きやすく、危険なものであるとCITP Blogは指摘しました。
◆すべてのインターネット投票システムは安全ではない
1：投票者のスマートフォンあるいはPCにマルウェアが潜んでいると、投票者が選択・確認した投票とは異なる投票内容が送信される可能性がある
2：サーバー上のマルウェアまたは内部関係者が投票結果を変更する可能性がある
3：選挙事務所にマルウェアが侵入すると投票結果が改ざんされる可能性がある
◆エンドツーエンドで検証可能なインターネット投票システムも安全ではない
1：有権者は確認のためにコンピューターアプリに頼らなければなりませんが、その確認アプリがマルウェアに感染していれば、 有権者にウソをつく可能性があります。
2：有権者は、自分がどのように投票したかを他人に証明できないようにすべきです。専門用語では「レシートフリー」と呼ばれます。
3：信頼性が高く、レシートフリーのE2E-VIVチェックアプリを作るのは困難です。
4：チェックアプリは投票アプリとは別々にする必要があります。そうでなければ、マルウェア対策は全く機能しません。
5：たとえ一部の有権者がチェックアプリを使用したとしても、システムが不正行為を行っていると検知した場合(これがチェックアプリの目的)、有権者が選挙管理当局にそれを証明する方法はありません。
インターネット投票は既存の技術では安全に保護できないという科学的コンセンサスは、数十年にわたって形成されてきました。将来の技術に関する研究は確かに行う価値がありますが、E2E-VIVシステムに関する数十年にわたる研究は、根本的な問題に対する解決策、あるいは解決の希望さえも生み出していないとCITP Blogは主張しています。
CITP Blogは「インターネット投票システムに関して、選挙管理当局やジャーナリストは『プレスリリースによる科学』に特に注意を払うべきです。いつか、科学的な調査に耐えうるインターネット投票ソリューションが提案されるかもしれないからです。それを評価する最も信頼できる方法は、査読済みの科学論文です。評判の高いサイバーセキュリティ会議や学術誌は、この分野で多くの優れた科学論文を発表しています」と記しました。
⇧ なるほど、「投票する側」が利用する「コンピューターノード」が「信頼」できる状態かを精査する術が確立されておりませんと...
⇧ 上記の「文部科学省」の公開している「ドキュメント」で、「産学官連携」とありますが、「インターネット投票」については「学」で停滞している感じなんですかね...
AzureのNSG（Network Security Groups）の各ルールについて図解して欲しいよね...
職場の方に連携してもらい、確かに「Microsoft Azure」の「NSG（Network Security Groups）」って、
- どういうシステム構成間の通信の許可、拒否のルールなのか
が分かり辛いと思ったので、備忘録として。
公式の「ドキュメント」によりますと、
Default security rules
Azure creates the following default rules in each network security group that you create:
https://learn.microsoft.com/en-us/azure/virtual-network/network-security-groups-overview
⇧「デフォルト セキュリティ規則」が用意されており、
In the Source and Destination columns, VirtualNetwork, AzureLoadBalancer, and Internet are service tags rather than IP addresses. In the Protocol column, Any encompasses TCP, UDP, and ICMP. When creating a rule, you can specify TCP, UDP, ICMP, or Any. 0.0.0.0/0 in the Source and Destination columns represents all IP addresses. Clients like the Azure portal, Azure CLI, or PowerShell can use * or Any for this expression.
https://learn.microsoft.com/en-us/azure/virtual-network/network-security-groups-overview
You can't remove the default rules, but you can override them by creating rules with higher priorities.
https://learn.microsoft.com/en-us/azure/virtual-network/network-security-groups-overview
⇧ とありますと。
で、「Service tags」の説明を見ると、
Service tags
A service tag represents a group of IP address prefixes from a given Azure service. It helps minimize the complexity of frequent updates on network security rules.
https://learn.microsoft.com/en-us/azure/virtual-network/network-security-groups-overview
For more information, see Azure service tags. For an example on how to use the Storage service tag to restrict network access, see Restrict network access to PaaS resources.
https://learn.microsoft.com/en-us/azure/virtual-network/network-security-groups-overview
⇧ とあり、「Microsoft Azure」側でIPアドレスの範囲を「サービス」に割り当てしたものらしいですと。
一応、
⇧ 上記で「Service tags」の全量が確認できるっぽい。
例えば、「デフォルト ネットワーク規則」の「Inbound（受信セキュリティ規則）」で「AllowVNetInBound」という「NSG（Network Security Groups）」の場合は、異なる「Azure 仮想ネットワーク（Azure VNet：Azure Virtual Network）」からの「通信」を許可するということになると思われる。
で、
多層防御を提供するには、各ホップに含まれるか、パケットが内部セグメントを通過するときに使用するセキュリティ アフォーダンスのエンド ツー エンドの制御を維持します。 リスク レベルが異なると、異なるリスク修復方法が必要になります。
https://learn.microsoft.com/ja-jp/azure/well-architected/security/networking
ネットワーク セキュリティ グループ
ネットワーク セキュリティ グループは、サブネットまたはネットワーク インターフェイス カード (NIC) レベルで適用するレイヤー 3 およびレイヤー 4 のファイアウォールです。 ネットワーク セキュリティ グループは、既定では作成も適用もされません。
https://learn.microsoft.com/ja-jp/azure/well-architected/security/networking
⇧ まさかの2種類の「NSG（Network Security Groups）」が存在する...
でもって、
の違いについての説明が無い...
おそらくは、
| No | NSGの種類 | 関係するリソース |
|---|---|---|
| 1 | Subnet NSG | Azure 仮想ネットワーク（Azure VNet：Azure Virtual Network） |
| 2 | NIC NSG | Azure 仮想マシン（Azure Virtual Machine） |
⇧ という関係になるのではないかと思われる。
で、
オンプレミスのネットワーク境界
Azure では、オンプレミス ネットワークとの接続を確立するための主な方法として、インターネット プロトコル (IPsec) トンネル、ExpressRoute トンネル、ソフトウェア定義型 WAN (SD-WAN) トンネルなどがあります。 通常、Azure サイト間 (S2S) VPN 接続は、必要とする帯域幅が少ない小規模なワークロードに使用します。 専用のサービス パスを必要とする、より高いスループットのニーズがあるワークロードの場合、Microsoft では ExpressRoute をお勧めします。
https://learn.microsoft.com/ja-jp/security/zero-trust/azure-networking-segmentation
⇧ 上記で「オンプレミス環境」との「通信」について言及されているのだが、そもそも、「NSG（Network Security Groups）」の「デフォルト セキュリティ規則」の「InBound（受信セキュリティ規則）」の「DenyAllInBound」は、外部から「Azure」環境に送られて来る全ての「通信」をブロックしているはずなのよね...
そして、
セグメント化の概要
次の表は、さまざまなレベルのセグメント化とセキュリティの方法をまとめたものです。
https://learn.microsoft.com/ja-jp/security/zero-trust/azure-networking-segmentation
⇧ 上記の説明だと、
- オンプレミス環境のマシン
- Azure環境内のマシン
との間で「通信」を確立したい場合に適切な対応が分からない...
仮に、「オンプレミス環境」から「Azure 仮想ネットワーク（Azure VNet：Azure Virtual Network）」に「通信」が届く「ネットワーク」構成になっていたとして、「NSG（Network Security Groups）」で「受信セキュリティ規則」を追加していないとするならば、「デフォルト セキュリティ規則」の「InBound（受信セキュリティ規則）」の「DenyAllInBound」を上書きされないと思われるからして、全ての「通信」が弾かれる気がするのよね...
まぁ、「Web画面」とかのある「アプリケーション」などの場合は、「Application Gateway」などでリクエストを受け付けて、最終的に「通信」が届くようにしないといけないので、「HTTP」などの「プロトコル」について「NSG（Network Security Groups）」の「受信セキュリティ規則」を追加する必要があるとは思うのだが...
つまり、「オンプレミス環境」との「通信」に関する「ネットワーク」の話とか出てくるのだが、どのような「通信」の時にどのような「NSG（Network Security Groups）」の「ルール」が必要になるのかについての重要な「情報」に関しては、具体的な説明がされていないという...
ちなみに、
⇧ 上記の例だと、「Application Gateway」とか挟まずに直で「通信」しておりますな...
ちなみに、「Microsoft Azure」だと「Network interface（NIC）」となっており、一般的な物理マシンの「Network Interface Card（NIC）」とは異なる模様...
本当に、「Microsoft Azure」内の独自の「用語」を使うのであれば、「用語」の定義について説明をして欲しいのよ...
そして、
Create, change, or delete a network interface
A network interface (NIC) enables an Azure virtual machine (VM) to communicate with internet, Azure, and on-premises resources. This article explains how to create, view and change settings for, and delete Azure network interfaces using the Azure portal, PowerShell, and CLI.
⇧ とあることから、外部からの「通信」を受け付るには、「NIC NSG（Network Security Groups）」の「受信セキュリティ規則」の追加が必要ということですな。
勿論、「Subnet NSG（Network Security Groups）」側でブロックされていても「通信」は到達できないはずですし、
Microsoft のお勧めは、インターネットからのイングレス トラフィックには、単一のエントリ ポイントを設定することです。 Microsoft では、イングレス トラフィックが Azure Firewall、Azure Front Door、Azure Application Gateway などの Azure PaaS リソースを通過するようにすることを強くお勧めします。 これらの PaaS リソースは、パブリック IP アドレスを持つ仮想マシンよりも多くの機能を提供します。
https://learn.microsoft.com/ja-jp/security/zero-trust/azure-networking-segmentation
⇧ 上記にあるように、他の「Azure PaaS（Platform as a Servce）」でブロックされてる場合も「通信」は到達されないはずでありますと...
そして、そもそも、「Azure」環境外である送信元側で、外部に対する「通信」に関する「OutBound」の「設定」で「通信」が許可されていない場合にも、「Azure」環境へ「通信」が到達しないことになりますと...
ちなみに、「Azure 仮想ネットワーク（Azure VNet：Azure Virtual Network）」間の「通信」についても語られていませんですしな...
何と言うか、最も肝心な「セキュリティ」に関わる話について、詳細な「情報」が語られていないという状態で、誠に遺憾である...
ちなみに、
⇧「Stackoverflow」で質問が上がるぐらいには「Microsoft」の公式の「ドキュメント」の「情報」のクオリティが低いってことになるんかね...
ちなみに、
Security rules
A network security group contains network security rules as desired, within Azure subscription limits. Each rule specifies the following properties:
https://learn.microsoft.com/en-us/azure/virtual-network/network-security-groups-overview
⇧ 公式の「ドキュメント」によると「番号」が小さいほど「優先」されるらしいので、「デフォルト セキュリティ規則」を超えるような数になって来ると、「デフォルト セキュリティ規則」の「ルール」を上書きすることはできないと...
何も考えずに、「1」とか利用すると、後から「ルール」を上書きできなかったりするので、「番号」の割り当ての見積もりが悩ましい...
最早、「ファインダビリティ（Findability）」云々以前の話になって来てしまっている気がしますな...
本当に必要とする「情報」に辿り着けないのよね...
何と言うか、「DX（Developer eXperience）」が改善されませんな...
毎度モヤモヤ感が半端ない…
今回はこのへんで。
