機能の提供状況
| クライアントモード | Zero Trust プラン ↗ |
|---|---|
|
すべてのプラン |
| システム | 提供状況 |
|---|---|
| Windows | ✅ |
| macOS | ✅ |
| Linux | ✅ |
| iOS | ✅ |
| Android | ✅ |
| ChromeOS | ✅ |
Access for Infrastructure では、個々のサーバー、クラスター、データベースへのユーザーアクセスを細かく制御できます。リソースへの認証方法に加え、利用できるポート、プロトコル、ユーザー名も設定できます。
ターゲットはタグで整理できます。ホスト名、タグ、またはその両方で一致するアプリケーションも定義できます。Access ログとコマンドログでアクセスを監査し、コンプライアンスの作業を支援できます。
cloudflaredまたは Cloudflare Mesh を使い、インフラストラクチャを Cloudflare に接続します。- ユーザーデバイスに Cloudflare One Client を Traffic and DNS mode でデプロイします。
ターゲットは、ユーザーが Cloudflare 経由で接続するインフラ上の 1 つのリソースです(サーバー、Kubernetes クラスター、データベース、コンテナなど)。
ターゲットはプロトコル非依存です。サーバー上で動くプロトコルごとに新しいターゲットを定義する必要はありません。新しいターゲットを作成する手順は次のとおりです。
- Cloudflare ダッシュボード ↗ で、Zero Trust > Access controls > Targets を開きます。
- Add a target を選びます。
- Target hostname に、ターゲット の分かりやすい名前を入力します。サーバーのホスト名(例:
production-server)の使用を推奨します。ターゲットホスト名は一意である必要はなく、複数ターゲットで再利用できます。ホスト名は Access アプリケーションが保護するターゲットの定義に使い、DNS の名前解決には使いません。ホスト名の形式制限
- 大文字小文字を区別しない
- 253 文字以内
- 英数字、
-、.のみ(スペースは不可) - 先頭と末尾は英数字
- IP addresses に、ターゲットリソースの IPv4 または IPv6 アドレス(あるいは両方)を入力します。完全な IP アドレスを入力するまで、ドロップダウンは候補を出しません。
- ドロップダウンで、リソースがある IP アドレスと 仮想ネットワーク を選びます。この IP アドレスと仮想ネットワークの組み合わせは、このターゲットに割り当てられ、設計上ほかのターゲットでは再利用できません。
- (任意)Tags で、ターゲットを整理するキーと値のタグを追加します。たとえば
environment、team、regionでターゲットをグループ化し、あとから ターゲット条件 で一致させます。各タグキーは、1 つのターゲットに 1 回だけ使えます。たとえば、1 つのターゲットにenvironment:productionまたはenvironment:stagingは付けられますが、両方は付けられません。 - Add target を選びます。
Infrastructure Access Targets エンドポイントへ POST リクエストを送ります。
curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/infrastructure/targets" \
--request POST \
--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
--json '{
"hostname": "infra-access-target",
"ip": {
"ipv4": {
"ip_addr": "187.26.29.249",
"virtual_network_id": "c77b744e-acc8-428f-9257-6878c046ed55"
},
"ipv6": {
"ip_addr": "64c0:64e8:f0b4:8dbf:7104:72b0:ec8f:f5e0",
"virtual_network_id": "c77b744e-acc8-428f-9257-6878c046ed55"
}
},
"tags": {
"environment": "production",
"team": "platform"
}
}'tags フィールドは任意です。タグの管理には Resource Tagging を使います。各キーは、ターゲットごとに 1 回だけ使えます。
-
cloudflare_api_token↗ に、次の権限を追加します。Zero Trust Write
-
cloudflare_zero_trust_infrastructure_access_target↗ リソースを設定します。resource "cloudflare_zero_trust_infrastructure_access_target" "infra-ssh-target" { account_id = var.cloudflare_account_id hostname = "infra-access-target" ip = { ipv4 = { ip_addr = "187.26.29.249" virtual_network_id = "c77b744e-acc8-428f-9257-6878c046ed55" } ipv6 = { ip_addr = "64c0:64e8:f0b4:8dbf:7104:72b0:ec8f:f5e0" virtual_network_id = "c77b744e-acc8-428f-9257-6878c046ed55" } } }Terraform でタグを管理するには、
cloudflare_resource_tag↗ リソースを使います。
次に、ターゲットを保護する Access アプリケーションを作成します。
インフラストラクチャターゲットには、キーと値の リソースタグ を付けられます。環境、チーム、リージョンなどのメタデータでターゲットを整理できます。
一致する値を持つターゲットを自動で対象にするインフラストラクチャアプリケーションも定義できます。
タグは、ターゲットの作成時や編集時にインラインで管理できます。Resource Tagging API でも管理できます。
1 つのターゲットに、同じタグキーは 1 つだけ付けられます。たとえば、ターゲットは environment:production か environment:staging のどちらか一方だけです。両方は付けられません。
タグの値でターゲットをフィルターし、並べ替えできます。
Cloudflare ダッシュボード ↗ で、Zero Trust > Access controls > Targets を開きます。フィルターと並べ替えのコントロールで、タグのキーまたは値により一覧を絞り込みます。
タグでターゲットをフィルターするには、1 つ以上の tag クエリパラメーターを追加します。
curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/infrastructure/targets?tag=environment:production&tag=team:platform" \
-H "Authorization: Bearer $API_TOKEN"各フィルターでは、タグキーと値の間に : を使います。tag パラメーターを複数追加すると、Cloudflare は AND ロジックを適用します。
タグキーで並べ替えるには、order と direction パラメーターを使います。
curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/infrastructure/targets?order=tag:environment&direction=asc" \
-H "Authorization: Bearer $API_TOKEN"並べ替えパラメーターも order=tag:<key> の形で : を使います。並べ替え対象のタグフィールドを指定するためです。
-
Cloudflare dashboard ↗ で Zero Trust > Access controls > Applications を開きます。
-
Create new application を選びます。
-
Infrastructure を選びます。
-
アプリケーションに任意の名前を入力します。
-
Target criteria で、このアプリケーションが対象とするターゲットを選びます。hostname、タグ、またはその両方でターゲットを照合します。いずれかの値に一致させる場合は
includeを使います。すべての値に一致させる場合はrequireを使います。一致するターゲットを除外する場合はexcludeを使います。 -
サーバーへの接続に使う Protocol と Port を入力します。
-
(任意)プロトコルが複数のポートで動く場合は、Add new target criteria を選び、同じターゲット条件とプロトコルを別のポート番号で再設定します。
-
Next を選びます。
-
ターゲットを保護するために、接続できる人と接続方法を定義するポリシーを設定します。
-
ポリシーに任意の名前を入力します。
-
ターゲットに到達できるユーザーに一致するルールを作成します。詳細は Access ポリシー を参照し、インフラストラクチャポリシーのセレクター の一覧を確認します。
-
Connection context で、次の設定を行います。
- SSH user: ユーザーがログインできる UNIX ユーザー名を入力します(例:
rootまたはec2-user)。 - Allow users to log in as their email alias: (任意)選択すると、ポリシー定義に一致するユーザーは、小文字化したメールアドレスのプレフィックスでターゲットにアクセスできます。たとえば
[email protected]はjdoeとしてログインできます。
- SSH user: ユーザーがログインできる UNIX ユーザー名を入力します(例:
-
-
Add application を選びます。
Access applications エンドポイントに POST リクエストを送ります。
次の例は、include、require、exclude を使う演算子ベースのターゲット条件形式です。
Required API token permissions
At least one of the following token permissions is required:Access: Apps and Policies Write
curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/access/apps" \
--request POST \
--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
--json '{
"name": "Example infrastructure app",
"type": "infrastructure",
"target_criteria": [
{
"port": 22,
"protocol": "SSH",
"include": {
"target_attributes": {
"hostname": [
"infra-access-target"
]
},
"tags": {
"environment": [
"production",
"staging"
]
}
},
"require": {
"tags": {
"team": [
"platform"
]
}
},
"exclude": {
"tags": {
"lifecycle": [
"decommissioned"
]
}
}
}
],
"policies": [
{
"name": "Allow a specific email",
"decision": "allow",
"include": [
{
"email": {
"email": "[email protected]"
}
}
],
"connection_rules": {
"ssh": {
"usernames": [
"root",
"ec2-user"
]
}
}
}
]
}'ターゲット条件の形式の詳細は Target criteria を参照してください。
-
cloudflare_api_token↗ に次の権限を追加します。Access: Apps and Policies Write
-
cloudflare_zero_trust_access_application↗ リソースを使って、インフラストラクチャアプリケーションを作成します。resource "cloudflare_zero_trust_access_application" "infra-app" { account_id = var.cloudflare_account_id name = "Example infrastructure app" type = "infrastructure" target_criteria { port = 22 protocol = "SSH" target_attributes { name = "hostname" values = ["infra-access-target"] } } }タグでターゲットを照合するには、
tagsセレクター付きのinclude、require、またはexcludeブロックを定義します。 -
cloudflare_zero_trust_access_policy↗ リソースを使って、アプリケーションにインフラストラクチャポリシーを追加します。resource "cloudflare_zero_trust_access_policy" "infra-app-policy" { application_id = cloudflare_zero_trust_access_application.infra-app.id account_id = var.cloudflare_account_id name = "Allow a specific email" decision = "allow" precedence = 1 include { email = ["[email protected]"] } connection_rules { ssh { usernames = ["root", "ec2-user"] } } }
このアプリケーション内のターゲットは、インフラストラクチャポリシーで保護されます。
デフォルトでは、Cloudflare はすべての Gateway のネットワークポリシー を評価したあとで、Access アプリケーションポリシーを評価します。特定の Gateway ポリシーの前または後に Access アプリケーションを評価するには:
Cloudflare ダッシュボード ↗ で、Zero Trust > Traffic policies > Firewall policies を開きます。Network で、次の構成の ネットワークポリシーを作成 します。
セレクター 演算子 値 アクション Access Infrastructure Target is Present Allow ダッシュボードまたは API を使い、ポリシーの 優先順位 を更新します。
この Gateway ポリシーは、RDP と SSH を含む、すべての Access for Infrastructure ターゲットに適用されます。
SSH で接続する前に、独立した MFA を要求できます。アプリケーション設定では、対応するインフラストラクチャ認証方式を選びます。PIV キー(piv_key)、FIDO2 キー(ssh_fido2_key)、またはその両方です。
アプリケーションレベルの設定で、デフォルトの認証方式とセッション期間を定義します。ポリシーでは、特定のユーザーまたはユーザー名向けにカスタム設定を定義できます。
セットアップ手順は、インフラストラクチャアプリケーションに MFA を適用する を参照してください。
一部のプロトコルでは、Access for Infrastructure 経由の接続を信頼するようサーバーを設定する必要があります。詳細は、プロトコルごとのチュートリアルを参照してください。
SSH の場合は、Cloudflare SSH CA を信頼します。サーバーが証明書のプリンシパルを制限している場合は、ターゲットに設定した SSH ユーザー名を許可します。
ユーザーは、好みのクライアントソフトウェアでターゲットの IP アドレスに接続します。デバイスで Cloudflare One Client にログインしている必要があります。それ以外のシステム設定は不要です。任意で プライベート DNS リゾルバー を設定すると、ターゲットのプライベートホスト名でも接続できます。
別の VNET にあるターゲットへ接続するには、Cloudflare One Client で 接続中の仮想ネットワークを切り替えます。
機能の提供状況
| システム | 提供状況 | 最小クライアントバージョン |
|---|---|---|
| Windows | ✅ | 2024.9.346.0 |
| macOS | ✅ | 2024.9.346.0 |
| Linux | ✅ | 2024.9.346.0 |
| iOS | ❌ | |
| Android | ❌ | |
| ChromeOS | ❌ |
ユーザーは warp-cli で、アクセスできるターゲットの一覧を表示できます。デバイスでターミナルを開き、次のコマンドを実行します。
warp-cli target list╭──────────────────────────────────────┬──────────┬───────┬───────────────────────┬──────────────────────┬────────────╮
│ Target ID │ Protocol │ Port │ Attributes │ IP (Virtual Network) │ Usernames │
├──────────────────────────────────────┼──────────┼───────┼───────────────────────┼──────────────────────┼────────────┤
│ 0193f22a-9df3-78e3-b5bb-7ab631903306 │ SSH │ 22 │ hostname: do-target │ 10.116.0.3 (a1net) │ alice │
├──────────────────────────────────────┼──────────┼───────┼───────────────────────┼──────────────────────┼────────────┤
│ 0193f22a-9df3-78e3-b5bb-7ab631903306 │ SSH │ 23 │ hostname: do-target │ 10.116.0.3 (a1net) │ root │
├──────────────────────────────────────┼──────────┼───────┼───────────────────────┼──────────────────────┼────────────┤
│ 01943cff-6130-7989-8bff-cbc02b59a2b1 │ SSH │ 80 │ hostname: az-target │ 172.16.0.0 (b1net) │ alice, bob │
╰──────────────────────────────────────┴──────────┴───────┴───────────────────────┴──────────────────────┴────────────╯任意でフラグを追加し、出力をフィルターできます。例:
warp-cli target list --attribute hostname=do-target --username root利用できるフィルターをすべて見るには、warp-cli target list --help を実行します。
すべてのインフラストラクチャターゲットへのユーザーアクセスを取り消すには、Zero Trust からユーザーを取り消すか、デバイスを取り消します。特定のターゲットだけユーザーのセッションを取り消す機能は、現時点ではありません。
Infrastructure Access は、Cloudflare のロールベースアクセス制御 によるきめ細かい読み取り権限に対応します。管理者は、アカウント全体のアクセスを付与せず、特定のターゲットに限定した読み取り専用ロールを割り当てられます。スコープ付きロールのユーザーが targets list API を呼び出すと、応答は閲覧権限のあるターゲットだけに自動で絞り込まれます。
チームに自チームのインフラストラクチャターゲットだけを見せ、ターゲット一覧全体は公開したくない組織に向いています。
ターゲット条件で、インフラストラクチャアプリケーションが対象とするターゲットを定義します。各ターゲット条件エントリには、プロトコル、ポート、およびホスト名、タグ、またはその両方でターゲットを一致させるセレクターが含まれます。
target_attributes セレクターが対応するのは、レガシー形式でも演算子ベース形式でも hostname だけです。それ以外の target_attributes キーは Cloudflare が拒否します。
ターゲットは、タグキーごとに 1 つの値だけ保存できます。この制限はターゲット条件には適用されません。たとえば、アプリケーションは include、require、exclude で environment:production と environment:staging の両方に一致できます。
| 演算子 | ロジック | 説明 |
|---|---|---|
include |
OR | ターゲットは、含められたセレクターのうち少なくとも 1 つに一致する必要があります。 |
require |
AND | ターゲットは、必須のセレクターすべてに一致する必要があります。 |
exclude |
NOT(OR) | 除外セレクターのいずれかに一致するターゲットは拒否されます。 |
組み合わせ評価: (いずれかの include)AND(すべての require)AND NOT(いずれかの exclude)。
既存のホスト名のみのアプリケーションでは、フラットな target_attributes 形式を引き続き使えます。これは API または Terraform でアプリケーションを管理する場合だけ関係します。ターゲット条件エントリごとに、フラットな target_attributes か、演算子ベースの include、require、exclude のどちらか一方を選びます。
インフラストラクチャアプリケーションを保護するために使える Access ポリシーセレクター は次のとおりです。
- Emails ending in
- SAML group
- Country
- Authentication method
- Device posture
- Entra group、GitHub organization、Google Workspace group、Okta group