Bonnes pratiques pour sécuriser vos ressources AlloyDB pour PostgreSQL

Pour vous aider à adopter une stratégie de sécurité solide pour vos ressources AlloyDB pour PostgreSQL, suivez les bonnes pratiques fournies sur cette page.

Empêcher le détournement du chemin de recherche

Pour éviter le piratage du chemin de recherche, définissez le paramètre search_path sur pg_catalog pour les utilisateurs disposant de privilèges élevés. Cette configuration sécurise le chemin de recherche afin que les schémas non approuvés tels que public soient ignorés.

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 sur la sécurisation du schéma public, 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 étrangères

Lorsque vous utilisez le wrapper de données étrangères (FDW) BigQuery, toutes les requêtes d'AlloyDB vers BigQuery sont authentifiées à l'aide du compte de service du cluster AlloyDB. Comme 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 standards de mapper des tables non autorisées.

Pour appliquer le principe du moindre privilège, limitez les droits USAGE sur le serveur étranger afin que les utilisateurs non administrateurs ne puissent pas exécuter d'instructions CREATE FOREIGN TABLE :

  1. Limitez USAGE sur le serveur étranger : empêchez les rôles non administrateurs de disposer des droits USAGE et révoquez USAGE de PUBLIC si nécessaire.

  2. Centralisez la création de tables : autorisez uniquement les administrateurs de base de données, tels que les utilisateurs disposant du rôle alloydbsuperuser, à créer des tables externes.

  3. Accorder un accès sélectif : gérez 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 standard (bob) l'accès à une table BigQuery spécifique sans lui permettre de mapper des ensembles de données arbitraires :

  1. En tant qu'administrateur, créez le serveur étranger et révoquez les droits USAGE de PUBLIC pour empêcher la création non autorisée de tables :

    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;

  2. En tant qu'administrateur, créez un mappage d'utilisateur pour l'utilisateur standard :

    CREATE USER MAPPING FOR bob SERVER bq_server;

  3. En tant qu'administrateur, créez la table étrangère :

    -- Because 'bob' does not have USAGE on bq_server, only the administrator can run this.
CREATE FOREIGN TABLE example_table (
    id INT,
    state VARCHAR
) SERVER bq_server OPTIONS (
    project 'BIGQUERY_PROJECT_ID',
    dataset 'BIGQUERY_DATASET_NAME',
    table 'example_table'
);

  4. En tant qu'administrateur, accordez un accès en lecture sélectif à la table externe spécifique à l'utilisateur standard :

    GRANT SELECT ON public.example_table TO bob;