Inbound Private Link prend désormais en charge Genie One au niveau du compte, la console de compte et les URL personnalisées

Les entreprises qui adoptent Databricks pour leurs données les plus sensibles s'appuient généralement sur Inbound Private Link pour maintenir le trafic des utilisateurs vers Databricks hors de l'internet public, en le routant de manière privée via leur propre réseau cloud. À mesure que les clients se déploient sur de nombreux espaces de travail, plusieurs régions et des produits au niveau du compte comme Genie One, nous avons étendu les capacités d'Inbound Private Link pour répondre à leurs besoins.

Nouveautés d'Inbound Private Link

Inbound Private Link prend désormais en charge les ressources au niveau du compte, notamment Genie One au niveau du compte, la console de compte, Governance Hub et les API au niveau du compte. Les clients peuvent placer Genie One au niveau du compte derrière Inbound Private Link avec les mêmes garanties réseau qu'ils appliquent déjà partout ailleurs.

Inbound Private Link prend désormais en charge les URL personnalisées et les URL stables de reprise après sinistre gérée. Inbound Private Link fonctionne désormais de bout en bout avec des URL personnalisées telles que acme.databricks.com. Cela s'étend aux URL stables de reprise après sinistre gérée (par exemple, acme.databricks.com/?c=stable-ws-id).

Un seul point de terminaison, n'importe quelle région, pour chaque ressource UI + API. Un unique point de terminaison General Access partagé dans n'importe quelle région peut désormais desservir toutes les interfaces utilisateur (UI) et API au niveau de l'espace de travail et du compte. Les clients n'ont plus besoin de créer un point de terminaison par région ou par espace de travail. Les équipes ayant des exigences strictes en matière d'isolation réseau peuvent toujours utiliser plusieurs points de terminaison ; mais ces points de terminaison ne sont plus limités à la desserte de ressources dans la même région. Cela réduit le travail manuel et les coûts nécessaires à la maintenance de nombreux points de terminaison. Remarque : les points de terminaison service-direct (pour les services gourmands en performances) et les points de terminaison de relais SCC (pour la connectivité sécurisée des clusters de calcul classique) doivent toujours être configurés par région.

Basé sur l'accès entrant basé sur le contexte

Ces nouvelles capacités d'Inbound Private Link sont intégrées aux contrôles d'accès entrant basés sur le contexte, qui permettent aux administrateurs de compte de rédiger des règles d'autorisation et de refus précises basées sur qui appelle (identité), depuis où (source réseau : IP publique ou point de terminaison enregistré) et ce qu'ils sont autorisés à atteindre dans l'espace de travail ou la ressource au niveau du compte (destination).

Les stratégies pour les ressources au niveau du compte, comme la console de compte, peuvent être définies dans la nouvelle account-policy.

Les stratégies d'espace de travail existantes comportent une nouvelle section « accès privé » pour la configuration d'Inbound Private Link basée sur le contexte.

Les stratégies Inbound Private Link pour l'accès général (general access) et le service-direct peuvent être configurées dans l'accès entrant basé sur le contexte. Combiné avec la prise en charge existante de l'accès public, l'accès entrant basé sur le contexte vous offre un moteur de stratégie unique pour configurer l'accès entrant public et privé pour les espaces de travail et les ressources au niveau du compte.

Nous recommandons aux clients de configurer l'accès entrant basé sur le contexte plutôt que des listes d'accès IP de type tout-ou-rien ou des paramètres d'accès privé (Private Access Settings) afin de tirer le meilleur parti des dernières capacités de notre plateforme.

Configuration minimale, aucune interruption pour les clients existants

Si vous utilisez déjà Inbound Private Link, cette version est additive et sans interruption. Les URL spécifiques à l'espace de travail non personnalisées continuent de fonctionner en parallèle avec l'accès par URL personnalisée. Les paramètres d'accès privé et les listes d'accès IP continuent de fonctionner en parallèle avec l'accès entrant basé sur le contexte (tout refus de stratégie entraîne un rejet).

L'activation de l'accès privé aux ressources au niveau du compte se fait en deux étapes :

1. Enregistrez et autorisez un point de terminaison General Access pour vos ressources au niveau du compte à l'aide de l'account-policy d'accès entrant basé sur le contexte.
2. Résolvez par DNS votre URL personnalisée vers ce point de terminaison General Access.

Prise en main

• Configurez Inbound Private Link pour les ressources au niveau du compte (AWS, Azure)
• Découvrez le contrôle d'accès entrant basé sur le contexte et la gestion des stratégies d'accès entrant (AWS, Azure)
• Examinez Inbound Private Link pour les espaces de travail (AWS, Azure) et le Private Link service-direct (AWS, Azure)

Toutes les nouvelles capacités d'Inbound Private Link décrites ici sont désormais disponibles en version bêta sur le niveau AWS Enterprise et le niveau Azure Premium. Les contrôles d'accès entrant basés sur le contexte pour l'accès public sont généralement disponibles. Essayez-les dès aujourd'hui !

(Cet article de blog a été traduit à l'aide d'outils basés sur l'intelligence artificielle) Article original