Bonnes pratiques pour sécuriser vos ressources AlloyDB pour PostgreSQL

Pour vous aider à renforcer la sécurité de vos ressources AlloyDB pour PostgreSQL, suivez les bonnes pratiques décrites sur cette page.

Empêcher le détournement de chemin de recherche

Pour empêcher le détournement de chemin de recherche, assurez-vous que le paramètre search_path est défini sur pg_catalog pour les utilisateurs disposant de droits d'accès élevés. Cela permet de sécuriser le chemin de recherche et de contourner les schémas non fiables tels que public.

Pour définir ce paramètre de manière permanente pour un utilisateur, exécutez la commande suivante :

ALTER ROLE USER_NAME SET search_path = pg_catalog,pg_temp;

Pour définir ce paramètre uniquement pour la session en cours, exécutez la commande suivante :

SET search_path TO pg_catalog,pg_temp;

Pour définir ce paramètre pour tous les utilisateurs lorsqu'ils sont connectés à une base de données, exécutez la commande suivante :

ALTER DATABASE DB_NAME SET search_path TO schema1, schema2, public;

Pour en savoir plus, consultez la documentation PostgreSQL sur l'utilisation sécurisée des schémas et le guide CVE-2018-1058.

Sécuriser l'accès aux données BigQuery à l'aide du wrapper de données externes

Lorsque vous utilisez le wrapper de données externes (FDW) BigQuery, toutes les requêtes d'AlloyDB vers BigQuery sont authentifiées à l'aide du compte de service du cluster AlloyDB. Étant donné que ce compte de service peut avoir accès à plusieurs ensembles de données BigQuery sensibles, il est essentiel d'empêcher les utilisateurs de base de données ordinaires de mapper des tables non autorisées.

Pour appliquer le principe du moindre privilège, les administrateurs doivent restreindre les droits d'accès USAGE sur le serveur externe. Cela empêche physiquement les utilisateurs non administrateurs d'exécuter des instructions CREATE FOREIGN TABLE.

  1. Restreignez USAGE sur le serveur externe en vous assurant que les rôles non administrateurs ne disposent pas des droits d'accès USAGE sur le serveur externe. Si nécessaire, révoquez-les de PUBLIC.
  2. Centralisez la création de tables : seuls les administrateurs de base de données, par exemple les utilisateurs disposant du rôle alloydbsuperuser, peuvent créer des tables externes.
  3. Accordez un accès sélectif : les administrateurs gèrent l'accès en lecture à l'aide de GRANT SELECT sur des tables externes spécifiques.

Exemple : Configurer l'accès selon le principe du moindre privilège

Le workflow suivant montre comment un administrateur peut accorder de manière sécurisée à un utilisateur ordinaire (bob) l'accès à une table BigQuery spécifique sans lui permettre de mapper des ensembles de données arbitraires.

-- Step 1: Create the server and restrict access (Executed as Administrator) ```sql CREATE EXTENSION IF NOT EXISTS bigquery_fdw; CREATE SERVER bq_server FOREIGN DATA WRAPPER bigquery_fdw;

-- Explicitly revoke USAGE from all users to prevent unauthorized table creation REVOKE ALL ON FOREIGN SERVER bq_server FROM PUBLIC; ```

-- Step 2: Create a User Mapping for the regular user (Executed as Administrator) sql CREATE USER MAPPING FOR bob SERVER bq_server;

-- Step 3: Create the Foreign Table (Executed as Administrator) -- Because 'bob' does not have USAGE on bq_server, only the administrator can run this. sql CREATE FOREIGN TABLE example_table ( id INT, state VARCHAR ) SERVER bq_server OPTIONS ( project 'BIGQUERY_PROJECT_ID', dataset 'BIGQUERY_DATASET_NAME', table 'example_table' );

-- Step 4: Grant Selective Read Access (Executed as Administrator) -- Explicitly grant read access to the regular user for this specific table. sql GRANT SELECT ON public.example_table TO bob;