Comment connecter un réseau de partenaires sur site à une passerelle API privée via AWS Direct Connect

Les exemples ci-dessous utilisent la région de Tokyo, ap-northeast-1.

external company network
172.20.0.0/16
│
├─Business client
│ curl / Java / Postman / Business system
│
├─ External Company DNS
│ Conditional forwarding:
│    api.partner.example.com
│           ↓
│    10.20.10.10
│    10.20.20.10
│
└─ External corporate router
     BGP
      │
      │ AWS Direct Connect
      ▼
Direct Connect Location
      │
      ▼
Direct Connect Gateway
      │
      ├─ Private VIF → VGW
      │ or
      └─ Transit VIF → Transit Gateway
                         │
                         ▼
                    AWS VPC
                    10.20.0.0/16
                         │
          ┌──────────────┴──────────────┐
          │                             │
          ▼                             ▼
Route 53 Resolver                Interface VPC Endpoint
Inbound Endpoint                 com.amazonaws.ap-northeast-1.execute-api
UDP/TCP 53                       TCP 443
10.20.10.10                      10.20.11.x
10.20.20.10                      10.20.21.x
          │                             │
          ▼                             │
Route 53 Private Hosted Zone            │
partner.example.com                     │
          │                             │
api.partner.example.com                 │
      Alias → VPC Endpoint ─────────────┘
                                        │
                                        ▼
                            API Gateway Private Domain
                                        │
                              Domain Access Association
                                        │
                                        ▼
                              API Mapping / Base Path
                                        │
                                        ▼
                              Private REST API Gateway
                                        │
                                        ▼
                         Lambda / AWS Service / VPC Link
                

Route 53 Resolver Inbound Endpoint reçoit des requêtes DNS du réseau local, tandis que Private Hosted Zone enregistre les noms de domaine privés; Interface VPC Endpoint est le point d'entrée réel pour les flux de données HTTPS dans API Gateway.

Supposons qu'un système d'entreprise externe demande:

https://api.partner.example.com/v1/orders
                

1. Processus de résolution du DNS

Le client demande d'abord à l'entreprise externe son DNS interne:

What is the IP of api.partner.example.com?
                

Envoi conditionnel configuré sur le DNS d'entreprise externe:

partner.example.com
    → 10.20.10.10
    → 10.20.20.10
                

Ces deux adresses IP sont les adresses IP de la route 53 Resolver Inbound Endpoint dans le VPC AWS.

La requête DNS est:

External company DNS
→ Direct Connect
→ Transit Gateway/VGW
→ Resolver Inbound Endpoint
→ Route 53 VPC Resolver
→ Private Hosted Zone
                

Existe dans la zone d'hébergement privé:

api.partner.example.com
    A Alias
    → vpce-xxxxxxxx.execute-api.ap-northeast-1.vpce.amazonaws.com
                

Ce qui est finalement retourné n'est pas l'IP publique de l'API Gateway, mais l'IP privée de l'ENI de l'interface VPC Endpoint, par exemple:

10.20.11.45
10.20.21.82
                

L'IP du point d'extrémité entrant est elle-même une IP privée VPC, donc le réseau local doit être redirigé vers le VPC via Direct Connect ou VPN. AWS exige que chaque point d'extrémité résolveur soit configuré avec au moins deux IP, et il est recommandé de les placer dans différentes zones de disponibilité.

2. processus d'accès HTTPS

Après la fin du DNS, le client établit TCP 443 à l'IP privée de VPC Endpoint résolue:

client
→ Direct Connect
→ TGW/VGW
→ VPC Endpoint ENI:443
→ AWS PrivateLink
→ API Gateway Private Custom Domain
→ API Mapping
→ Private REST API
                

C' est ici. Route 53 Resolver ne participe pas à l'envoi HTTPS de Il n'est responsable que de la résolution DNS précédente.

La passerelle API privée ne peut être accessible que par l'interface VPC Endpoint d'API Gateway, et la politique de ressources API doit également autoriser le VPC ou le VPC Endpoint spécifié.

1. Connexion directe AWS

fonction

Direct Connect fournit une connexion de ligne privée entre le réseau d'entreprise externe et AWS.

Elle est principalement chargée de:

• Enroulez le segment de réseau privé d'une entreprise externe vers un VPC AWS.
• Libérer le segment réseau AWS VPC à des entreprises externes.
• Il héberge les requêtes DNS.
• Il héberge les demandes d'API HTTPS.
• Évitez le trafic commercial qui passe par Internet public.
• Fournir une bande passante et une latence relativement stables.

Ce pour quoi Direct Connect n' est pas responsable

Direct Connect lui-même n'est pas responsable de:

• Résolution DNS.
• L'authentification de l'API.
• Autorisation de l'API.
• Le certificat TLS.
• Enroulement API Gateway.
• Encrivez automatiquement tous les liens.

Direct Connect est un "circuit privé", mais il ne peut pas être simplement égalé à un "circuit crypté de bout en bout". Lorsque le cryptage de lien est nécessaire, considérez MACsec où il est pris en charge, ou en superposant Site-to-Site VPN/IPsec sur Direct Connect. must_encrypt le mode arrête la transmission si le chiffrement ne peut pas être établi; should_encrypt peut revenir à la communication non cryptée en cas d'échec.

2. Route 53 Résolver Endpoint d'entrée

fonction

Permettre aux serveurs DNS des entreprises externes de consulter le DNS au sein du VPC AWS.

Sans elle, le DNS local de l'entreprise externe ne peut pas être consulté directement:

• Zone d'hébergement privé de la route 53.
• Nom DNS privé interne de VPC.
• Les dossiers privés liés au point final du VPC.

Après la création du point final entrant, une ENI sera créée dans le sous-réseau spécifié et une IP privée fixe sera attribuée.

Pourquoi je ne peux pas demander directement aux VPC VPC+2 Le DNS ?

Les adresses DNS communes dans VPC sont similaires:

VPC CIDR：10.20.0.0/16
VPC Resolver：10.20.0.2
                

Mais le réseau externe ne devrait pas utiliser directement 10.20.0.2 Le point d'entrée standard pour les réseaux hybrides est le Resolver Inbound Endpoint.

3. Route 53 Zone d'hébergement privé

fonction

Enregistrer les noms de domaine privés et les enregistrements correspondants, par exemple:

Private Hosted Zone:
partner.example.com

Record:
api.partner.example.com
    A Alias
    → execute-api Interface VPC Endpoint
                

La zone privée hébergée ne prend effet que pour le VPC associé et les requêtes entrées via le résolver entrant Endpoint correspondant. Il n'est pas nécessaire d'exposer l'adresse API réelle au DNS public.

4. Point d'extrémité de l'interface VPC

Nom du service:

com.amazonaws.ap-northeast-1.execute-api
                

fonction

Interface VPC Endpoint est l'entrée privée de Private API Gateway au sein de VPC.

Il crée un ENI dans chaque sous-réseau de zone de disponibilité sélectionné:

AZ-a：10.20.11.45
AZ-c：10.20.21.82
                

Les demandes HTTPS de sociétés externes atteignent finalement ces ENI et entrent ensuite dans l'API Gateway via AWS PrivateLink.

Interface Endpoint prend en charge:

• Groupe de sécurité.
• Politique des points d'extrémité du VPC:
• Zones de disponibilité multiples.
• Nom DNS privé.
• IPv4, IPv6 ou double pile, selon le service et la configuration.

AWS recommande que Interface Endpoint sélectionne plusieurs sous-réseaux pour améliorer la disponibilité.

5. API Gateway Domaine personnalisé privé

Par exemple:

api.partner.example.com
                

Elle résout deux problèmes:

Adresse d'appel conviviale

Pas besoin d' utiliser:

https://a1b2c3d4-vpce123.execute-api.ap-northeast-1.amazonaws.com/prod
                

Utilisez plutôt:

https://api.partner.example.com/v1
                

Certificat TLS

API Gateway est basé sur TLS SNI:

api.partner.example.com
                

Sélectionnez le certificat ACM correspondant.

Il doit être créé entre le domaine personnalisé privé et le point d'extrémité VPC:

Domain Name Access Association
                

Sinon, même si le DNS pointe vers le Endpoint, API Gateway ne permettra pas au Endpoint d'utiliser ce nom de domaine privé.

6. Portée d'API privée

La passerelle d'API privée est l'entrée finale de l'API.

Il peut continuer à intégrer:

• Le Lambda.
• Les services AWS.
• L'arrière-plan HTTP.
• Connectez-vous aux services ALB/NLB et intra-VPC par l'intermédiaire de VPC Link.

L'API privée ne signifie pas que " n'importe qui à travers la ligne dédiée peut l'appeler. " Au moins, les couches d'autorisation suivantes existent également:

VPC Endpoint Security Group
VPC Endpoint Policy
Private Domain Resource Policy
Private API Resource Policy
API method level authentication
Backend business certification
                

La politique en matière de ressources de l'API privée peut restreindre les sources par aws:SourceVpce ou aws:SourceVpc. AWS recommande de spécifier explicitement un VPC ou un VPC Endpoint au lieu d'autoriser toutes les origines.

Un exemple spécifique est donné ci-dessous.

Il est recommandé de séparer le point d'extrémité du résolveur et le point d'extrémité de l'interface dans un sous-réseau dédié pour faciliter:

• Configurer le NACL de manière indépendante.
• Des journaux de flux séparés.
• Identifier les coûts.
• Contrôle indépendant des groupes de routage et de sécurité.
• Remplacement ou expansion ultérieur.

Scénario A: Un seul VPC

Peut être utilisé:

Direct Connect
→ Private VIF
→ Direct Connect Gateway
→ Virtual Private Gateway
→ VPC
                

Le VIF privé est principalement utilisé pour accéder au VPC via IP privé. Lors de la création, vous devez définir des paramètres tels que VLAN, client BGP ASN, BGP Peer IP et MTU.

Option B: Plusieurs VPC ou centre réseau partagé

Il est recommandé:

Direct Connect
→ Transit VIF
→ Direct Connect Gateway
→ Transit Gateway
→ Shared Services VPC
                

Il s'agit d'une conception plus courante dans les environnements d'entreprise, car elle peut être suivie par:

• Le VPC du DNS.
• L'API VPC
• Le vice-président des affaires.
• Vérifiez la sécurité.

Accès unifié à la passerelle de transit.

Transit VIF est utilisé pour se connecter à la passerelle de transit associée à la passerelle de connexion directe; les préfixes autorisés de la passerelle de connexion directe affectent les préfixes côté AWS publiés sur le réseau local.

Pas de configuration de connexion directe

1. établir une connexion physique ou hébergée

Il peut s'agir de:

• Connexion dédiée.
• Connexion hébergée fournie par des partenaires.

Les environnements de production formels d'entreprise devraient éviter d'avoir un seul lien. Le modèle de haute disponibilité d'AWS recommande d'utiliser des connexions redondantes à partir de différents appareils et de différents emplacements de connexion directe, et vous pouvez utiliser le kit d'outils Resilience pour tester le failover BGP.

2. Créer une passerelle de connexion directe

Par exemple:

Name: dxgw-partner-api
Amazon side ASN: 64520
                

3. Créer une passerelle de transit

Par exemple:

TGW ASN: 64530
                

Accrochez le VPC où se trouve l'API au TGW.

4. Associer DX Gateway et TGW

Les préfixes autorisés doivent être définis, par exemple:

10.20.0.0/16
                

Ne publiez pas au hasard:

0.0.0.0/0
10.0.0.0/8
                

Sauf si c'est une conception web explicitement vérifiée.

5. Créer le VIF de transit

Parmi les paramètres clés figurent:

VLAN: 120
Customer ASN: 65010
AWS ASN: from DXGW
Customer Peer IP: 169.254.x.x/30
AWS Peer IP: 169.254.x.x/30
BGP MD5 Key: automatically generated or specified
MTU: 1500 or 8500
                

6. Configurer le routeur local

Publier localement sur AWS:

172.20.0.0/16
                

Les versions AWS pour les locaux:

10.20.0.0/16
                

7. Configurer la table de routage TGW

Le côté AWS exige au moins:

172.20.0.0/16
    → Direct Connect Gateway/TGW association direction
                

La table des itinéraires du sous-réseau VPC de l'API exige:

172.20.0.0/16
    → Transit Gateway
                

Le routeur d'entreprise externe nécessite:

10.20.0.0/16
    → Direct Connect
                

Connectez directement les erreurs les plus courantes

L'itinéraire est configuré dans une seule direction.

Par exemple:

Les entreprises externes peuvent atteindre 10.20.11.45
Mais AWS ne sait pas comment renvoyer le trafic vers 172.20.0.0/16
                

Le résultat est généralement un délai de connexion TCP.

Coupe de CIDR

Par exemple:

Entreprise externe : 10.20.0.0/16
AWS VPC：10.20.0.0/16
                

Cette situation ne peut pas être résolue par un routage ordinaire.

• Réorganisez l'adresse.
• NAT.
• Un agent intermédiaire.
• L'architecture basée sur les services PrivateLink.

MTU incohérent

Le VIF privé peut utiliser 1500 ou 9001, le VIF transit peut utiliser 1500 ou 8500. Avant d'activer Jumbo Frame, assurez-vous que le routeur du client, l'opérateur, le lien DX, le TGW et l'équipement intermédiaire le supportent tous. Sinon, les petites demandes peuvent être normales et les grandes demandes peuvent être bloquées.

1. Créer un groupe de sécurité

Par exemple:

sg-r53-inbound
                

Règles relatives aux entrées:

UDP 53
Source: External company DNS server IP/32

TCP 53
Source: External company DNS server IP/32
                

Par exemple:

UDP 53  ← 172.20.1.10/32
UDP 53  ← 172.20.1.11/32
TCP 53  ← 172.20.1.10/32
TCP 53  ← 172.20.1.11/32
                

Ne pas simplement ouvrir UDP 53. TCP peut être utilisé dans les situations suivantes:

• La réponse DNS est trop grande.
• DNSSEC.
• Essayez à nouveau après la coupure UDP.
• Le comportement de certains produits DNS internes.

AWS exige explicitement que le groupe de sécurité Inbound Endpoint autorise TCP et UDP 53.

2. Créer un point d'arrivée

Parcours de la console:

Route 53
→ Resolver
→ Inbound endpoints
→ Create inbound endpoint
                

Les paramètres recommandés:

Name: r53-inbound-partner-api
VPC: vpc-api-shared
Endpoint category: Default
Protocol: Do53
Security Group: sg-r53-inbound
                

Configurer deux AZ:

AZ-a
Subnet: subnet-dns-a
IP: 10.20.10.10

AZ-c
Subnet: subnet-dns-c
IP: 10.20.20.10
                

AWS exige un minimum de deux IP et recommande d'être dans différentes zones de disponibilité; ces IP restent inchangés pendant la durée de vie du point final.

3. Envoi conditionnel de la configuration DNS de l'entreprise externe

Exemple DNS de Windows:

Conditional Forwarder:
partner.example.com

Master Servers:
10.20.10.10
10.20.20.10
                

Exemple BIND:

zone "partner.example.com" {
    type forward;
    forward only;
    forwarders {
        10.20.10.10;
        10.20.20.10;
    };
};
                

Il est recommandé de transmettre uniquement le nom de domaine précis:

partner.example.com
                

Ne configurez pas inutilement:

.
com
example.com
                

Dans le cas contraire, un grand nombre de requêtes DNS non pertinentes peuvent être redirigées vers AWS.

4. Vérifiez le lien DNS

Testez directement l'IP de AWS Resolver:

dig @10.20.10.10 api.partner.example.com
                

Alors passez le test DNS normal de l'entreprise externe:

dig api.partner.example.com
                

À un stade précoce, lorsque la zone d'hébergement privé n'a pas été créée, NXDOMAIN peut être retourné, ce qui prouve au moins que la demande a atteint le résolveur.

1. Créer un groupe de sécurité Endpoint

Par exemple:

sg-vpce-execute-api
                

Règles relatives aux entrées:

TCP 443
Source: 172.20.0.0/16
                

Lorsqu'il est plus strict, seul le segment réseau du système d'entreprise est autorisé:

TCP 443
Source: 172.20.10.0/24
                

Ne commettez pas l'erreur de penser que le simple fait d'autoriser VPC CIDR suffit. L'appelant est situé dans un réseau d'entreprise externe. La source vue par VPC Endpoint est généralement l'IP privée originale de l'entreprise externe, il faut donc autoriser le segment réseau correspondant.

AWS exige que le groupe de sécurité Endpoint execute-api autorise le trafic HTTPS 443.

2. Créer un objectif final

Parcours de la console:

VPC
→ Endpoints
→ Create endpoint
                

Sélectionnez:

Service category: AWS services
Service:
com.amazonaws.ap-northeast-1.execute-api

Type:
Interface
                

Configuration:

VPC: vpc-api-shared
Subnets:
  subnet-endpoint-a
  subnet-endpoint-c

Security Group:
  sg-vpce-execute-api

Private DNS:
  Enabled
                

Il est recommandé de sélectionner au moins deux zones de disponibilité. Seul un sous-réseau peut être sélectionné pour chaque AZ sélectionné, et AWS créera un ENI d'Endpoint dans chaque sous-réseau.

Exemple d'AWS CLI:

aws ec2 create-vpc-endpoint \
  --region ap-northeast-1 \
  --vpc-id vpc-0123456789abcdef0 \
  --vpc-endpoint-type Interface \
  --service-name com.amazonaws.ap-northeast-1.execute-api \
  --subnet-ids subnet-aaa subnet-ccc \
  --security-group-ids sg-0123456789abcdef0 \
  --private-dns-enabled
                

3. L'impact du commutateur DNS privé

Après avoir activé l' execute-api DNS privé:

*.execute-api.ap-northeast-1.amazonaws.com
                

Dans le cadre de ce VPC, le VPC Endpoint sera résolu en premier.

Il est plus pratique d'appeler le nom de domaine par défaut de l'API privée, mais il a également des effets secondaires:

• Lors de l'accès à l'API public Gateway par défaut execute-api URL dans un VPC, il peut être résolu à Private Endpoint.
• Par conséquent, l'API publique peut ne pas être accessible par le nom de domaine par défaut.
• Il est préférable d'utiliser votre propre domaine régional personnalisé pour l'API du réseau public.

La documentation AWS rappelle clairement qu'après avoir activé le DNS privé d'exécution-api Endpoint, l'accès à l'API publique par l'intermédiaire du point d'exécution par défaut du VPC peut être affecté.

1. Créer une API

La console:

API Gateway
→ Create API
→ REST API
→ Build
                

Sélectionnez:

Endpoint type: Private
IP address type: Dualstack
VPC Endpoint IDs: vpce-xxxxxxxx
                

La passerelle API privée se réfère ici à REST API Endpoint privéUne fois associé, API Gateway génère le nom DNS d'appel lié à l'ID API et à l'ID Endpoint.

Exemple de CLI:

aws apigateway create-rest-api \
  --region ap-northeast-1 \
  --name partner-private-api \
  --endpoint-configuration '{
    "types":["PRIVATE"],
    "ipAddressType":"dualstack",
    "vpcEndpointIds":["vpce-0123456789abcdef0"]
  }'
                

2. Créer des ressources et des méthodes

Par exemple:

/
└── orders
    ├── GET
    └── POST
                

Ou bien:

/health
/orders
/orders/{orderId}
                

Après avoir configuré Lambda ou une autre intégration, déployer à:

Stage: prod
                

3. Politique en matière de ressources de l'API

Il est recommandé d'autoriser uniquement le point final spécifié:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": "*",
      "Action": "execute-api:Invoke",
      "Resource": "execute-api:/*"
    },
    {
      "Effect": "Deny",
      "Principal": "*",
      "Action": "execute-api:Invoke",
      "Resource": "execute-api:/*",
      "Condition": {
        "StringNotEquals": {
          "aws:SourceVpce": "vpce-0123456789abcdef0"
        }
      }
    }
  ]
}
                

La signification de cette façon d'écrire est:

1. En principe, les appels sont autorisés.
2. Mais tant que le point final source n'est pas le point final spécifié, il sera explicitement rejeté.

AWS fournit des exemples de politiques de ressources API privées basées sur aws:SourceVpce et aws:SourceVpc.

Après avoir modifié la politique des ressources, l'API doit être redéploiée.

1. Préparer le certificat ACM

Le certificat doit couvrir:

api.partner.example.com
                

Et le certificat doit être situé dans la région où se trouve l'API Gateway, par exemple:

ap-northeast-1
                

Vous pouvez utiliser:

api.partner.example.com
                

ou, le cas échéant:

*.partner.example.com
                

Le domaine privé personnalisé prend en charge les certificats de carte blanche, mais ne prend pas en charge le nom de domaine personnalisé de carte blanche lui-même; les noms de domaine privés utilisent toujours TLS 1.2.

Problèmes importants concernant les certificats publics ACM

Même si le nom de domaine est uniquement utilisé pour l'intranet, ACM doit toujours vérifier la propriété du nom de domaine lors de la demande d'un certificat public ACM.

Les enregistrements de vérification DNS doivent être découverts par l'ACM à partir du DNS public.

Par conséquent, une approche plus sûre est la suivante:

• Utilisez un sous-domaine de nom de domaine public qui appartient réellement à l'entreprise, tel que api.partner.example.com.
• Mettez uniquement le CNAME vérifié par ACM dans le DNS public.
• L'enregistrement A de l'API réelle est placé uniquement dans la zone d'hébergement privé.
• Le DNS du réseau public n'a pas besoin de publier l'adresse réelle de l'API.

2. Créer un domaine privé personnalisé

La console:

API Gateway
→ Custom domain names
→ Add domain name
                

Configuration:

Domain name:
api.partner.example.com

Endpoint type:
Private

Routing mode:
API mappings only

ACM Certificate:
Certificate covering api.partner.example.com
                

Après la création, API Gateway configurera initialement une politique qui refuse tout accès au nom de domaine et nécessite une autorisation manuelle pour spécifier le VPC Endpoint.

Exemple de CLI:

aws apigateway create-domain-name \
  --region ap-northeast-1 \
  --domain-name api.partner.example.com \
  --certificate-arn arn:aws:acm:ap-northeast-1:111122223333:certificate/xxxxxxxx \
  --security-policy TLS_1_2 \
  --endpoint-configuration '{"types":["PRIVATE"]}' \
  --policy file://domain-policy.json
                

Le domaine privé lui-même doit également permettre de spécifier le point final du VPC.

domain-policy.json：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": "*",
      "Action": "execute-api:Invoke",
      "Resource": "execute-api:/*"
    },
    {
      "Effect": "Deny",
      "Principal": "*",
      "Action": "execute-api:Invoke",
      "Resource": "execute-api:/*",
      "Condition": {
        "StringNotEquals": {
          "aws:SourceVpce": "vpce-0123456789abcdef0"
        }
      }
    }
  ]
}
                

Voici un point très facile à négliger:

Pour qu'une demande soit couronnée de succès, au moins ce qui suit doit être vrai:

Private Domain Policy allows
Private API Policy allows
VPC Endpoint Policy allows
Method level authentication allows
                

AWS exige explicitement l'API privée et le domaine personnalisé privé pour configurer les politiques de ressources séparément.

Par exemple, l'espoir:

https://api.partner.example.com/v1/orders
                

Carte de:

API: partner-private-api
Stage: prod
Base Path: v1
                

La console:

API Gateway
→ Custom domain names
→ api.partner.example.com
→ API mappings
→ Configure mappings
                

Les paramètres:

API: partner-private-api
Stage: prod
Path: v1
                

CLI:

aws apigateway create-base-path-mapping \
  --region ap-northeast-1 \
  --domain-name api.partner.example.com \
  --domain-name-id abcd1234 \
  --rest-api-id a1b2c3d4 \
  --stage prod \
  --base-path v1
                

Le domaine personnalisé privé doit être mappé à des API et étapes privées spécifiques par l'intermédiaire de règles de cartographie ou de routage de l'API.

C'est l'étape la plus facile à manquer dans l'architecture du domaine privé personnalisé.

Il faut construire:

Private Custom Domain
        ↕
execute-api VPC Endpoint
                

La console:

API Gateway
→ Custom domain names
→ api.partner.example.com
→ Resource sharing
→ Domain name access associations
→ Create
                

Sélectionnez:

Domain ARN:
arn:aws:apigateway:ap-northeast-1:111122223333:
/domainnames/api.partner.example.com+domain-id

VPC Endpoint:
vpce-0123456789abcdef0
                

CLI:

aws apigateway create-domain-name-access-association \
  --region ap-northeast-1 \
  --domain-name-arn \
  arn:aws:apigateway:ap-northeast-1:111122223333:/domainnames/api.partner.example.com+abcd1234 \
  --access-association-source vpce-0123456789abcdef0 \
  --access-association-source-type VPCE
                

Il peut prendre environ 15 minutes pour que l'association soit disponible après sa création, et il peut également prendre un certain temps pour la création du domaine privé personnalisé lui-même ou la mise à jour du certificat.

Contrôle de la politique des points d'extrémité:

Il n'est pas recommandé de maintenir un accès complet pendant de longues périodes.

Par exemple, seuls les domaines et API sont autorisés à être spécifiés:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": "*",
      "Action": "execute-api:Invoke",
      "Resource": [
        "arn:aws:execute-api:ap-northeast-1:111122223333:/domainnames/api.partner.example.com+abcd1234",
        "arn:aws:execute-api:ap-northeast-1:111122223333:a1b2c3d4/*"
      ]
    }
  ]
}
                

Vous pouvez également utiliser execute-api:viaDomainArn Pour restreindre l'accès uniquement au domaine privé personnalisé spécifié. AWS donne un exemple de restriction de la politique de VPC Endpoint par nom de domaine privé, API et méthode.

Notes d'en-tête d'autorisation

La politique des points finaux évalue d'abord les résultats de la demande. Authorization en-tête:

• Aucune autorisation: évaluée par le directeur anonyme.
• Correction SigV4: Identifié comme directeur de l'IAM.
• Erreur SigV4: rejet direct.
• Token porteur/JWT: La politique de point final est généralement toujours évaluée sur la base de Principal anonyme.

Par conséquent, si la couche commerciale utilise OAuth/JWT/Lambda Authorizer, ne demandez pas à tort un Utilisateur IAM dans la Politique des points d'arrêt, sinon les demandes légitimes de JWT peuvent être bloquées par la Politique des points d'arrêt.

1. Créer une zone d'hébergement privée

Il est recommandé de créer:

partner.example.com
                

et associer un PCV contenant les ressources suivantes:

• Résolvez le point final entrant.
• Exécuter-api VPC Endpoint。

Au moins la zone d'hébergement privée doit être associée au VPC où se trouve le point final entrant, afin que le résolveur puisse utiliser la zone d'hébergement pour répondre aux requêtes externes.

CLI:

aws route53 create-hosted-zone \
  --name partner.example.com \
  --caller-reference "$(date +%s)" \
  --hosted-zone-config Comment="Partner private API",PrivateZone=true \
  --vpc VPCRegion=ap-northeast-1,VPCId=vpc-0123456789abcdef0
                

2. Créer des enregistrements d'alias

La console:

Route 53
→ Hosted zones
→ partner.example.com
→ Create record
                

Configuration:

Record name:
api

Record type:
A

Alias:
On

Route traffic to:
Alias to VPC endpoint

Region:
ap-northeast-1

Endpoint:
vpce-0123456789abcdef0
                

L'objectif de l'alias Route 53 du domaine personnalisé API privé devrait être le point d'exécution de l'interface VPC de l'API, et non le point d'exécution Lambda, API ID ou Resolver.

Exemple d'enregistrement CLI:

{
  "Changes": [
    {
      "Action": "UPSERT",
      "ResourceRecordSet": {
        "Name": "api.partner.example.com",
        "Type": "A",
        "AliasTarget": {
          "DNSName": "vpce-0123456789abcdef0.execute-api.ap-northeast-1.vpce.amazonaws.com",
          "HostedZoneId": "VPC_ENDPOINT_HOSTED_ZONE_ID",
          "EvaluateTargetHealth": false
        }
      }
    }
  ]
}
                

Puis:

aws route53 change-resource-record-sets \
  --hosted-zone-id Z0123456789ABCDEFG \
  --change-batch file://api-alias.json
                

Si le point final utilise IPv6 ou Dualstack, ajoutez des enregistrements AAAA selon les besoins réels.

Les entreprises extérieures n'ont généralement besoin d'accéder qu'aux informations suivantes.

Informations sur le réseau

AWS target network segment:
10.20.0.0/16

Agreement:
DNS UDP/TCP 53
HTTPS TCP 443
                

Informations sur le DNS

Forwarding domain:
partner.example.com

DNS target:
10.20.10.10
10.20.20.10
                

Informations sur l'API

Base URL:
https://api.partner.example.com/v1

Health check:
GET /health

Business API:
GET /orders
POST /orders
                

Informations sur la certification

En fonction de la conception, par exemple:

• OAuth2/JWT。
• L'autorisation Lambda de l'API Gateway
• Il s'agit d'un outil d'exploitation de l'AWS IAM SigV4.
• La signature du HMAC.
• Cognito Token
• Nom d'utilisateur/mot de passe d'entreprise, ne doit pas être utilisé seul.
• La clé API ne convient qu'à la mesure et au plan d'utilisation et ne doit pas être utilisée comme seule authentification de sécurité.

L'API privée ne prend actuellement pas en charge la fonction TLS mutuelle de l'API Gateway, de sorte que l'authentification de certificats bidirectionnels B2B ne peut pas être configurée directement selon la méthode mTLS de l'API régionale du réseau public. Vous pouvez utiliser IAM SigV4, JWT/Lambda Authorizer, vérification des certificats de couche d'application ou redessiner la couche proxy avant.

Il est recommandé de diviser les contrôles en six couches.

Couche 1: Routage de connexion directe

Publier uniquement les segments de réseau nécessaires:

External Company → AWS:
10.20.0.0/16

AWS → External Company:
172.20.10.0/24
                

Essayez de ne pas publier des segments de réseau d'entreprise entiers les uns aux autres.

Deuxième couche: groupe de sécurité Resolver Endpoint

Seuls les serveurs DNS officiels de sociétés externes sont autorisés:

UDP/TCP 53
172.20.1.10/32
172.20.1.11/32
                

Ne permettez pas à tous les clients de consulter directement le Resolver.

La troisième couche: groupe de sécurité d'exécuter-api Endpoint

Seuls les segments de réseau source du système d'entreprise sont autorisés:

TCP 443
172.20.10.0/24
                

Couche 4: Politique des points d'extrémité des VPC

Seuls autorisés:

Specify Private Domain
Specify API
Specify method or stage
                

Couche 5: Politique de domaine et de ressources API

Elle a également été adoptée:

aws:SourceVpce
                

Limiter le point d'extrémité spécifié.

Lorsque vous devez restreindre davantage les IP d'origine externe, la politique de ressources API privée peut être utilisée:

aws:VpcSourceIp
                

Parce que VPC Endpoint peut réécrire l'IP source de la couche réseau, aws:VpcSourceIp est utilisé pour déterminer l'adresse source de la demande initiale.

Niveau 6: Certification au niveau des méthodes et des entreprises

Par exemple:

OAuth2 Access Token
JWT Claims
Partner ID
Scope
Order permissions
Call frequency
business audit
                

Le fait d'être accessible par le réseau ne signifie pas que l'entreprise a accès.

1. Le DNS de l'horizon divisé

Supposons que l'entreprise externe soit déjà gérée en interne:

example.com
                

AWS crée à nouveau:

Private Hosted Zone: example.com
                

Ensuite, des conflits de DNS et d'autorité peuvent survenir.

Il est plus recommandé de diviser les sous-domaines dédiés:

aws-api.example.com
partner-api.example.com
private.example.com
                

Il suffit alors de transmettre conditionnellement ce sous-domaine.

2. Erreur d'association de la zone privée hébergée

si:

Resolver Endpoint in VPC-A
Private Hosted Zone is only associated with VPC-B
                

Le point final entrant peut ne pas résoudre la zone d'hébergement comme prévu.

Le moyen le plus simple est:

Private Hosted Zone
Also associate the VPC where the Resolver Endpoint is located
And the VPC where the execute-api Endpoint is located
                

C'est plus facile si les deux sont dans le même VPC.

3. N'écrivez pas la propriété intellectuelle de Resolver dans l'entreprise

Une erreur:

api.partner.example.com
A → 10.20.10.10
                

10.20.10.10 est un serveur DNS, pas un serveur API.

C' est vrai .

api.partner.example.com
A Alias → execute-api VPC Endpoint
                

4. TTL et mise en cache

Après les modifications de l'enregistrement de la zone d'hébergement privé, le DNS d'entreprise externe et les clients peuvent continuer à utiliser le cache.

Lors du test, vous pouvez:

dig api.partner.example.com
                

Observez le TTL, et nettoyez:

• Le cache DNS de Windows.
• Le système d'exploitation systemd-resolved dans le cache.
• Le cache DNS Java JVM.
• La mise en cache du DNS de l'entreprise.

Connexion directe

Pour les environnements de production, considérez au moins:

DX Connection A
DX Connection B
different devices
Best Different DX Location
                

et préparer:

Site-to-Site VPN Backup
                

Utilisez les attributs BGP pour contrôler activement et en attente.

Résolver le point final entrant

Au moins deux AZ:

10.20.10.10
10.20.20.10
                

Le DNS externe est configuré avec deux expéditeurs en même temps.

Chaque IP Endpoint Resolver peut gérer un grand nombre de requêtes; la documentation AWS actuelle stipule qu'une seule IP peut gérer jusqu'à environ 10 000 UDP DNS QPS lorsque les conditions sont appropriées, mais la capacité réelle est affectée par la taille de la requête, le protocole, la latence de réponse et le suivi des connexions de groupe de sécurité.

Point d'extrémité de l'interface VPC

Au moins deux AZ:

Endpoint ENI A
Endpoint ENI C
                

L'alias de la route 53 renverra l'adresse correspondante du point final.

AWS recommande également clairement que les Domaines personnalisés privés utilisent des Endpoints VPC dans au moins deux zones de disponibilité.

Portée d'accès à l'API

API Gateway lui-même est un service d'hébergement régional et ne nécessite pas le déploiement d'instances actives et en attente de type EC2.

• La synchronisation Lambda.
• Le lien VPC:
• L'ALB/NLB présente plusieurs AZ.
• La base de données a plusieurs AZ.
• Récupération des catastrophes interrégionales.

Il est recommandé d'activer au moins les éléments suivants.

Connexion directe

Moniteur:

ConnectionState
VirtualInterfaceBpsIngress
VirtualInterfaceBpsEgress
VirtualInterfacePpsIngress
VirtualInterfacePpsEgress
BGP status
                

L'outil de résilience AWS prend en charge la vérification des itinéraires redondants en fermant temporairement la session BGP.

Route 53 résolver

Activer:

Resolver Query Logging
CloudWatch Resolver Endpoint Metrics
                

Rechercher les journaux peut aider à confirmer:

• Si une requête de nom de domaine a été reçue.
• De quel VPC vient la requête.
• C'est un type curieux.
• Retour des résultats.

Il convient de noter que les requêtes répétées touchées par le cache Resolver n'apparaissent généralement pas dans le journal de requête comme chaque requête indépendante.

VPC

Activer:

VPC Flow Logs
                

Les faits saillants:

• Résolvent le point d'extrémité ENI。
• exécuter-api Endpoint ENI。
• Traffic lié au TGW.
• Accepter ou rejeter:
• IP de source, IP de destination, port.

Portée d'accès à l'API

Activer:

Access Logs
Execution Logs
Detailed Metrics
AWS X-Ray, on demand
                

Il est recommandé que les journaux d'accès contiennent au moins:

$requestId
$context.identity.sourceIp
$context.domainName
$context.httpMethod
$context.resourcePath
$context.status
$context.responseLength
$context.integrationErrorMessage
                

Ne fuis pas tout simplement. curl d'abord, test par couche.

Étape 1: Vérifiez le BGP et le routage

Le routeur externe confirme avoir appris:

10.20.0.0/16
                

L'AWS confirme avoir appris:

172.20.0.0/16
                

Étape 2: Testez directement le résolveur

dig @10.20.10.10 api.partner.example.com A
dig @10.20.20.10 api.partner.example.com A
                

Étape 3: passer le test DNS formel par une entreprise externe

dig api.partner.example.com A
                

Il convient de renvoyer l'adresse IP privée du point final.

Étape 4: Testez TCP 443

nc -vz api.partner.example.com 443
                

Ou bien:

telnet api.partner.example.com 443
                

Étape 5: Vérifiez le certificat TLS

openssl s_client \
  -connect api.partner.example.com:443 \
  -servername api.partner.example.com
                

Vérifiez:

Subject Alternative Name
Issuer
Validity
TLS version
Certificate chain
                

Étape 6: Appelez le médecin

curl -v https://api.partner.example.com/v1/health
                

Étape 7: Appel avec authentification

Prenons l'exemple de JWT:

curl -v \
  -H "Authorization: Bearer ${TOKEN}" \
  https://api.partner.example.com/v1/orders
                

Les scénarios SigV4 peuvent utiliser le SDK, AWS CLI ou la bibliothèque de signatures correspondante qui prend en charge les signatures.

1. Délais d'expiration des demandes DNS

Des performances:

dig timeout
                

Contrôles prioritaires:

External DNS to Resolver IP routing
TGW routing
VPC subnet routing
Resolver SG UDP/TCP 53
external firewall
NACL
                

2. Le DNS renvoie le NXDOMAIN

Cela signifie que le réseau et le serveur DNS peuvent être connectés, mais il y a un problème avec la couche d'enregistrement.

Vérifiez:

Private Hosted Zone name
A Alias record
Hosted Zone is associated with VPC
Is the FQDN queried correct?
Is there a more specific conflict Hosted Zone
                

Le nom de domaine peut être résolu, mais TCP 443 fois hors.

Vérifiez:

execute-api Endpoint SG
External routing to Endpoint ENI
NACL
TGW backhaul routing
external firewall
                

4. Non-conformité du nom du certificat TLS

Par exemple, le certificat est:

*.example.com
                

Mais le nom de domaine est:

api.partner.example.com
                

*.example.com ne couvre qu'une seule couche:

api.example.com
                

Généralement non couverts:

api.partner.example.com
                

Il convient d'utiliser:

*.partner.example.com
                

ou un certificat exact:

api.partner.example.com
                

5. Retour 403 interdit

L'ordre de vérification:

Is Domain Name Access Association AVAILABLE?
Domain Resource Policy
API Resource Policy
VPC Endpoint Policy
MethodAuthorization
JWT/IAM signature
API Key/Usage Plan
                

6. Retourner le jeton d'authentification manquant

Motifs communs:

Base Path error
Stage mapping error
HTTP method error
Resource path does not exist
API not redeployed
                

Par exemple, la cartographie réelle:

/v1 → prod
                

C' est vrai .

https://api.partner.example.com/v1/orders
                

Une erreur:

https://api.partner.example.com/prod/orders
                

7. L'URL par défaut d'exécution-api peut être consultée, mais le domaine personnalisé ne peut pas

Les points clés à vérifier:

ACM certificate
Private Domain status
Domain Resource Policy
Domain Access Association
API Mapping
Route 53 Alias
Host/SNI
                

8. Elle peut être consultée au sein du PCV, mais pas par des sociétés externes.

Généralement dit:

API Gateway configuration is basically correct
The problem is focused on DX routing, Endpoint SG or external DNS
                

9. Les petites demandes sont normales, mais les grandes échouent.

Vérifiez:

MTU
PMTUD
ICMP Fragmentation Needed
intermediate firewall
Jumbo Frame
                

1. Direct Connect n'est pas automatiquement crypté.
2. DNS et HTTPS sont deux chemins différents.
3. Les États membres Le résolver Endpoint doit ouvrir à la fois UDP et TCP 53.
4. La zone d'hébergement privé doit être associée au VPC où se trouve le résolveur.
5. L'alias cible est l'exécution-api VPC Endpoint, pas Resolver.
6. Les États membres Exécuter-api Le groupe de sécurité Endpoint doit permettre le segment TCP 443 du réseau source de l'entreprise externe.
7. La politique de domaine privé et la politique d'API privée sont deux politiques.
8. doit créer une association d'accès aux noms de domaine.
9. doit être redéployé après modification de l'association ou de la ressource Endpoint de l'API.
10. L'enregistrement de vérification DNS du Le certificat public ACM doit être consultable à partir du DNS public et ne peut être placé que dans la zone d'hébergement privée.

La configuration suivante est recommandée pour les systèmes B2B formels:

Two Direct Connect
+ VPN backup link

Transit VIF
+ Direct Connect Gateway
+ Transit Gateway

Standalone Shared Services VPC

Resolver Inbound Endpoint of two AZs
+ Only allow official DNS servers UDP/TCP 53

execute-api Interface Endpoint of two AZs
+ Only allow external business network segment TCP 443

Dedicated private subdomain
api.partner.example.com

Private Custom Domain
+ ACM Certificate
+ Domain Access Association

Private Domain Policy
+ API Resource Policy
+ Endpoint Policy
All restrictions aws:SourceVpce

JWT or IAM SigV4 authentication
+ API Gateway Access Logs
+ Resolver Query Logs
+ VPC Flow Logs
+ DX CloudWatch Alert
                

Le lien final peut être résumé comme suit:

DNS：
External DNS
→ Direct Connect
→ Resolver Inbound Endpoint
→ Private Hosted Zone
→ Return to VPC Endpoint private IP

HTTPS：
External business system
→ Direct Connect
→ execute-api Interface Endpoint
→ Private Custom Domain
→ API Mapping
→ Private REST API
→ Backend services