こんにちは!インフラやセキュリティの世界へようこそ。
初めてクラウドを触る時、「インターネット経由でどこからでもアクセスできる」というクラウドの便利さに感動しますよね。でも、その便利さの裏側には、「世界中のどこからでも、悪意ある攻撃者からあなたのデータにアクセスできる」というリスクが常に隣り合わせになっています。
今回は、AzureのPaaS(データベースやストレージなど)を安全に守るための強力な盾、「Azure Private Linkとプライベートエンドポイント」について、身近な防犯の仕組みに例えながら、一歩ずつ優しく紐解いていきましょう!
—
1. なぜ「パブリックアクセス」は危険なの?(家の鍵に例えてみる)
まずは、よくあるセキュリティの盲点からお話しますね。
皆さんがAzureでデータベース(例えばAzure SQL Databaseなど)やストレージ(Azure Storage)を作ったとします。初期設定のままだと、これらのリソースには「パブリックIPアドレス」という、インターネットの世界地図上でどこにあるか丸見えの住所が割り当てられます。
これって、例えるなら「自宅の玄関の鍵を開けっぱなしにして、さらに『我が家の宝箱はここにあります!』と世界中に住所の看板を立てている状態」なんです。
もちろん、ユーザー名やパスワード(合鍵)があれば簡単には入れませんが、攻撃者はあらゆる手を使ってその合鍵を破ろうとしたり、パスワードの隙をついて侵入を試みます。
「じゃあ、社内のネットワークからしかアクセスできないようにすればいいのでは?」
その通りです!そこで登場するのが、今回解説する Azure Private Link です。
—
2. Azure Private Link とプライベートエンドポイントってなに?
難しそうな名前が出てきましたが、仕組みはとってもシンプルです。
- プライベートエンドポイント(Private Endpoint):あなたの仮想ネットワーク(VNet)の中に作る「専用の通用口(ドア)」です。
- Private Link:その専用ドアと、AzureのPaaSリソースを安全につなぐ「誰にも盗聴されない専用の地下通路」です。
これを導入するとどうなるか?
先ほどの例えで言うと、「家の外にある玄関(パブリックアクセス)を完全に壁で塞ぎ、自分たちの敷地内からしか入れない『秘密の地下通路(プライベートエンドポイント)』を掘る」ことになります。
これなら、インターネットという危険な外の世界を一切通らずに、安全にクラウドのデータベースやストレージにアクセスできるようになりますよね。パブリックアクセスを完全に遮断できるため、外からの不正アクセスのリスクを劇的に減らすことができるんです。
—
3. 実践!プライベートエンドポイントを構築してみよう
それでは、実際にAzure環境でどのようにこれを構成するのか、具体的な手順と設定のポイントを見ていきましょう。今回は、Azure Storage(Blobストレージ)を例に解説しますね。
設定の全体像としては、以下の3ステップを進めます。
1. パブリックアクセスを完全に禁止する(玄関を塞ぐ)
2. 仮想ネットワーク内にプライベートエンドポイントを作る(秘密のドアを作る)
3. プライベートDNSゾーンを設定する(秘密のドアへの道案内を作る)
ステップ1: パブリックアクセスの完全遮断
まずは、ストレージアカウントがインターネットから見えないように設定します。Azure Portalや、Infrastructure as Code(Terraformなど)を使って設定しますが、今回は現場でよく使われるTerraformのコード例を見てみましょう。
# ストレージアカウントのリソース定義
resource "azurerm_storage_account" "secure_store" {
name = "mystorageaccount001"
resource_group_name = azurerm_resource_group.rg.name
location = azurerm_resource_group.rg.location
account_tier = "Standard"
account_replication_type = "LRS"
# 【重要】これがパブリックアクセスを遮断する設定です!
# 「false」にすることで、インターネットからの通信を完全に拒否します。
public_network_access_enabled = false
tags = {
Environment = "Production"
}
}
この設定を行うことで、ストレージアカウントへのインターネット経由の入り口は完全に消滅します。
ステップ2: プライベートエンドポイントの作成
次に、社内ネットワーク(VNet)側から安全にアクセスするための「専用のドア」を作ります。ここではサブネットの中にプライベートIPアドレス(例: 10.0.1.5 など)が割り当てられます。
# プライベートエンドポイントの作成
resource "azurerm_private_endpoint" "storage_pe" {
name = "st-private-endpoint"
location = azurerm_resource_group.rg.location
resource_group_name = azurerm_resource_group.rg.name
# エンドポイントを配置する社内ネットワークのサブネットIDを指定
subnet_id = azurerm_subnet.internal_subnet.id
private_service_connection {
name = "st-privateserviceconnection"
# 接続先のストレージアカウントのリソースIDを指定
private_connection_resource_id = azurerm_storage_account.secure_store.id
# ストレージのBlobサービスを指定(接続するPaaSの種類によって変わります)
subresource_names = ["blob"]
# 手動承認が必要かどうか(今回は不要なのでfalse)
is_manual_connection = false
}
}
ステップ3: プライベートDNSゾーンの構成(ここが一番のハマりポイント!)
インフラ初心者が一番ハマりやすいのがここです。
プライベートエンドポイントを作ると、仮想ネットワーク内に専用のIPアドレス(例: 10.0.1.5)が割り当てられますが、アプリからストレージにアクセスする時は、通常 mystorageaccount001.blob.core.windows.net のようなドメイン名(名前)を使いますよね。
ここで、パソコンが「この名前のIPアドレスを教えて!」と探しに行った時、もし通常のインターネット上の住所(パブリックIP)を返されてしまうと、せっかく作ったプライベートエンドポイントにたどり着けません。
そのため、「社内ネットワークの中だけで通用する秘密の電話帳(プライベートDNSゾーン)」を用意し、そのドメイン名を聞かれたら、先ほどのプライベートIP(10.0.1.5)を返すように設定する必要があります。
# プライベートDNSゾーンの作成(Blobストレージ用)
resource "azurerm_private_dns_zone" "storage_dns" {
name = "privatelink.blob.core.windows.net"
resource_group_name = azurerm_resource_group.rg.name
}
# 仮想ネットワークとプライベートDNSゾーンのリンク(電話帳を共有する設定)
resource "azurerm_private_dns_zone_virtual_network_link" "dns_vnet_link" {
name = "st-dns-vnet-link"
resource_group_name = azurerm_resource_group.rg.name
private_dns_zone_name = azurerm_private_dns_zone.storage_dns.name
virtual_network_id = azurerm_virtual_network.vnet.id
}
# プライベートエンドポイントとDNSレコードを紐付ける設定
resource "azurerm_private_dns_a_record" "dns_a" {
name = "mystorageaccount001"
zone_name = azurerm_private_dns_zone.storage_dns.name
resource_group_name = azurerm_resource_group.rg.name
ttl = 300
# プライベートエンドポイントに割り当てられたIPアドレスを指定
records = [azurerm_private_endpoint.storage_pe.private_service_connection[0].private_ip_address]
}
このDNSの設定を行うことで、アプリはこれまで通り名前を指定するだけで、自動的に安全な地下通路(プライベートエンドポイント)を通ってストレージにたどり着けるようになります!
—
4. 現場のプロが教える「陥りがちな罠」とインシデント回避の知見
最後に、現場のインフラエンジニアが思わず冷や汗をかくような「実際のトラブル事例」をシェアしますね。
よくあるのが、「プライベートエンドポイントを作ったのに、なぜかアプリから接続エラー(タイムアウト)になる」という現象です。
その原因の多くは、以下の2点にあります。
1. ネットワーク セキュリティ グループ(NSG)のブロック
- プライベートエンドポイントを配置したサブネットや、アプリが動いているサブネットのNSG(ファイアウォールルール)で、通信がブロックされていませんか?「安全な通路」を作っても、その通路の入り口に鍵がかかっていては意味がありません。通信に必要なポート(ストレージなら
443など)がきちんと許可されているか確認しましょう。
2. カスタムDNSサーバー(オンプレミス連携など)の泥沼
- Azure標準のDNSではなく、企業独自のオンプレミス側のDNSサーバーを使っている環境では、
privatelink.blob.core.windows.netの名前解決がうまく転送されず、古いパブリックIPを引いてしまうトラブルが頻発します。条件付きフォワーダーの設定が正しく行われているか、構築後に必ずnslookupコマンドなどで名前解決のテストを行いましょう。
—
まとめ
いかがでしたでしょうか?
今回は、Azure Private Linkとプライベートエンドポイントについて、防犯の例えを交えながら解説しました。
- インターネット経由のアクセス(パブリックアクセス)は、いわば鍵の開いた玄関。思い切って遮断しましょう!
- 仮想ネットワーク内に「プライベートエンドポイント」という安全な専用ドアを作りましょう。
- 最後に「プライベートDNSゾーン」で正しい道案内をしてあげることを忘れないようにしましょう。
セキュリティの対策は、一つひとつ紐解いていけば決して難しくありません。一歩ずつ、安全で堅牢なクラウド環境を一緒に作っていきましょう!それでは、また次のセキュリティ解説でお会いしましょう!
コメント