How to change data - Data Management - Centre de documentation Alibaba Cloud

Dans Data Management (DMS), la modification de données sans garde-fous présente des risques : une instruction DELETE en production peut avoir des conséquences désastreuses, et un TRUNCATE erroné est irréversible. DMS répond à cette problématique grâce à des règles de sécurité qui déterminent quelles instructions SQL s'exécutent directement dans la console SQL, lesquelles nécessitent l'approbation d'un ticket et lesquelles sont entièrement bloquées. Cette rubrique décrit quatre scénarios courants en mode de collaboration sécurisée afin de vous aider à configurer la politique de gouvernance adaptée à chaque environnement.

Fonctionnement

Chaque modification de données dans DMS suit ce cycle de vie :

Étape	Description
Rédaction du code SQL	Saisissez les instructions SQL dans la console SQL ou joignez un fichier `.sql`, `.txt` ou `.zip` à un ticket.
Pré-vérification	DMS valide automatiquement le code SQL par rapport à vos règles de sécurité avant l'exécution.
Approbation	Si les règles de sécurité l'exigent, la modification est soumise aux approbateurs désignés (par défaut, les administrateurs de base de données).
Execute	Exécutez la modification immédiatement ou planifiez-la. Vous pouvez éventuellement encapsuler les instructions DML (Data Manipulation Language) dans une seule transaction.
Sauvegarde et restauration	DMS peut générer des instructions de sauvegarde pour les opérations `UPDATE` et `DELETE`, permettant ainsi une restauration si nécessaire.

Le comportement à chaque étape est régi par des règles de sécurité, c'est-à-dire des politiques configurables associées à chaque instance de base de données.

Prérequis

Avant de commencer, assurez-vous de disposer des éléments suivants :

Un compte administrateur DMS, ou les autorisations nécessaires pour soumettre des tickets de modification de données
Les instances de base de données poc_prod et poc_dev enregistrées dans DMS en mode de collaboration sécurisée
La table data_modify créée dans les deux bases de données

Création de la table data_modify

Dans les quatre exemples de cette rubrique, la fonctionnalité Conception de schéma de DMS a été utilisée pour créer la table data_modify. Vous pouvez également exécuter cette instruction directement dans la console SQL ; les instructions DDL dans les bases de données de développement ne nécessitent pas de ticket pour être exécutées.

CREATE TABLE `data_modify` (
 `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT COMMENT 'Primary key',
 `name` varchar(256) NOT NULL COMMENT 'Name',
 `phone` varchar(32) DEFAULT NULL COMMENT 'Phone number',
 `sex` varchar(32) DEFAULT NULL COMMENT 'Gender',
 `email` varchar(256) DEFAULT NULL COMMENT 'Email address',
 `remarks` varchar(1024) DEFAULT NULL COMMENT 'Remarks',
 PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='Personal information';

Les ensembles de règles de sécurité utilisés dans les quatre scénarios :

Instance de base de données	Ensemble de règles de sécurité
`poc_dev`	Règles de sécurité pour les bases de données de développement POC
`poc_prod`	Règles de sécurité pour les bases de données de production POC

Soumission d'un ticket pour une modification standard des données

Ce scénario consiste à insérer des lignes dans la table data_modify de poc_prod en soumettant un ticket de modification de données.

Connectez-vous à la console DMS V5.0console DMS V5.0.
Placez le pointeur sur l'icône située dans le coin supérieur gauche, puis choisissez All Features > Database Development > Data Change > Normal Data Modify.

En mode normal, choisissez Database Development > Data Change > Normal Data Modify dans la barre de navigation supérieure.

Remplissez les paramètres du ticket. Paramètres clés :

Paramètre	Description
SQL text	L'instruction SQL à exécuter. Séparez plusieurs instructions par des points-virgules (`;`).
Attachment	Téléchargez un fichier `.txt`, `.zip` ou `.sql`. Taille maximale du fichier : 15 Mo.

Cliquez sur Submit. DMS effectue automatiquement une pré-vérification. Si celle-ci échoue, mettez à jour le code SQL comme indiqué et soumettez-le à nouveau.
Une fois la pré-vérification réussie, cliquez sur Submit for Approval, puis sur OK dans l'invite de confirmation.

Par défaut, les tickets de modification de données sont approuvés par les administrateurs de base de données. Pour modifier le modèle d'approbation par défaut, consultez la section Modification du modèle d'approbation par défaut de la rubrique Correction SQL.

Après l'approbation du ticket, cliquez sur Execute Change. Dans la boîte de dialogue Task Settings, configurez les paramètres d'exécution et cliquez sur Confirm Execution.

Si vous définissez Execution Method sur After Audit Approved, Auto Execute lors de l'étape de demande, cette étape est automatiquement ignorée. Après la reprise d'une tâche suspendue, l'exécution se poursuit là où elle s'était arrêtée.

Paramètre	Description
Execution strategy	Running immediately (par défaut) : exécute dès que le ticket est confirmé. Schedule : exécute à l'heure spécifiée.
Enable Submit as Single Transaction	Par défaut : désactivé. Activé : si une instruction DML échoue, toutes les instructions DML de la transaction sont restaurées (les instructions DDL ne peuvent pas être restaurées). Désactivé : chaque instruction s'exécute indépendamment ; l'exécution s'arrête en cas d'échec, mais les instructions précédentes ne sont pas restaurées.
Enable Backup	Par défaut : activé. DMS génère des instructions de sauvegarde pour les instructions `UPDATE` et `DELETE`. Consultez la section Prise en charge de la sauvegarde pour plus de détails spécifiques à la base de données.

Facultatif. Une fois l'exécution terminée, ouvrez la console SQL pour poc_prod et vérifiez les résultats.

Prise en charge de la sauvegarde

La sauvegarde s'applique uniquement aux instructions UPDATE et DELETE. INSERT et les instructions DDL ne sont pas sauvegardées.

Type de base de données	Instruction de sauvegarde générée	Notes
MySQL, MariaDB	`REPLACE INTO`	Inclut ApsaraDB RDS for MySQL, PolarDB for MySQL, PolarDB-X et MySQL autogéré
Toutes les autres bases de données prises en charge	`INSERT`	—
MongoDB, Redis	Non pris en charge	—

Autoriser l'exécution directe des instructions DML dans la base de données de développement

Par défaut, les règles de sécurité de DMS exigent que toutes les instructions DML passent par des tickets. Pour les bases de données de développement, cela ralentit l'itération. Configurez les règles de sécurité pour permettre aux développeurs d'exécuter des instructions DML directement dans la console SQL, sans soumettre de ticket à chaque fois.

Étape 1 : Mise à jour des règles de sécurité pour poc_dev

Connectez-vous à la console DMS V5.0console DMS V5.0 en tant qu'administrateur DMS.
Placez le pointeur sur l'icône située dans le coin supérieur gauche, puis choisissez All Features > Security and disaster recovery (DBS) > Security Rules.

En mode normal, choisissez Security and disaster recovery (DBS) > Security Rules dans la barre de navigation supérieure.

Placez le pointeur sur l'icône située dans le coin supérieur gauche, puis choisissez All Features > Security and disaster recovery (DBS) > Security Rules.

Remarque
Si vous utilisez la console DMS en mode normal, choisissez Security and disaster recovery (DBS) > Security Rules dans la barre de navigation supérieure.

Placez le pointeur sur l'icône située dans le coin supérieur gauche, puis choisissez All Features > Security and disaster recovery (DBS) > Security Rules.

Remarque
Si vous utilisez la console DMS en mode normal, choisissez Security and disaster recovery (DBS) > Security Rules dans la barre de navigation supérieure.

Placez le pointeur sur l'icône située dans le coin supérieur gauche, puis choisissez All Features > Security and disaster recovery (DBS) > Security Rules.

Remarque
Si vous utilisez la console DMS en mode normal, choisissez Security and disaster recovery (DBS) > Security Rules dans la barre de navigation supérieure.
Sur la page Security Rules, repérez les règles de la base de données de développement POC et cliquez sur Edit dans la colonne Actions.
Dans le volet de navigation de gauche, cliquez sur SQL Correct. Définissez Checkpoints sur SQL execution rules.
Activez All DML can execute directly in SQLConsole et désactivez All DML must execute by ticket.

Étape 2 : Vérification de la modification de règle

Dans le coin supérieur gauche de la console DMS, recherchez l'instance poc_dev.

Dans l'onglet SQLConsole, exécutez les instructions INSERT suivantes :

INSERT INTO data_modify (name, phone, sex) VALUES ('dms_a', '19000001','Male');
INSERT INTO data_modify (name, phone, sex) VALUES ('dms_b', '19000002','Female');
INSERT INTO data_modify (name, phone, sex) VALUES ('dms_c', '19000003','Male');

Dans la boîte de dialogue Execution Confirmation, cliquez sur Execute. Si Executed apparaît dans le résultat, la modification de règle fonctionne correctement.

Exiger l'approbation par ticket pour le SQL à haut risque dans la base de données de production

Certaines instructions SQL, comme DELETE, présentent un risque important en production. Configurez les règles de sécurité pour identifier DELETE comme étant à haut risque et le diriger vers un processus d'approbation dédié.

Étape 1 : Création d'un processus d'approbation

Connectez-vous à la console DMSconsole DMS en tant qu'administrateur DMS.
Placez le pointeur sur l'icône située dans le coin supérieur gauche, puis choisissez All Features > Security and disaster recovery (DBS) > Approval Processes.

En mode normal, choisissez Security and disaster recovery (DBS) > Approval Processes dans la barre de navigation supérieure.
Cliquez sur Create Approval Template et configurez les nœuds d'approbation. Ajoutez les nœuds par ordre croissant : le nœud 1 correspond au premier approbateur, le nœud 2 au second, et ainsi de suite.
Cliquez sur Submit.

Étape 2 : Configuration d'une règle d'identification des risques

Placez le pointeur sur l'icône située dans le coin supérieur gauche, puis choisissez All Features > Security and disaster recovery (DBS) > Security Rules.

En mode normal, choisissez Security and disaster recovery (DBS) > Security Rules dans la barre de navigation supérieure.
Sur la page Security Rules, repérez les règles de la base de données de production POC et cliquez sur Edit dans la colonne Actions.
Cliquez sur SQL Correct dans le volet de navigation de gauche. Définissez Checkpoints sur Risk Identification Rules et cliquez sur Create Rule.

Dans la boîte de dialogue Create Rule - SQL Correct, définissez les paramètres suivants :

Paramètre	Valeur
Rule name	`Production environments. The execution of DELETE statements is a high-risk operation`
Rule DSL	Voir le code DSL ci-dessous

if
    @fac.env_type in ['product','pre']
    and
    @fac.sql_type in
    [ 'DELETE']
then
    @act.mark_risk 'high' 'High-risk SQL statements: DELETE in the production environments'
end

Cliquez sur Submit.
Repérez la règle Production environments. The execution of DELETE statements is a high-risk operation et cliquez sur Enable dans la colonne Actions. Cliquez sur OK dans le message de confirmation. La règle prend effet immédiatement : toutes les instructions DELETE sont identifiées comme des opérations à haut risque.

Étape 3 : Liaison du processus d'approbation à la règle d'approbation des risques

Définissez Checkpoints sur Risk Approval Rules. Repérez la règle High risk approval process et cliquez sur Edit dans la colonne Actions.
Dans la boîte de dialogue Change Rule - SQL Correct, remplacez l'ID du modèle dans le champ Rule DSL par l'ID du modèle d'approbation créé à l'étape 1. Cliquez sur Submit.
Repérez la règle High risk approval process et cliquez sur Enable. Cliquez sur OK pour confirmer.

Étape 4 : Vérification de la règle

Dans la console DMS, recherchez l'instance poc_prod.
Dans l'onglet SQLConsole, exécutez l'instruction suivante :
```
DELETE FROM data_modify WHERE id = 1;
```
Si la zone Historique des exécutions affiche un message d'échec dû aux règles de sécurité, la règle fonctionne. Cliquez sur Apply for Data Change pour soumettre un ticket et suivre le processus d'approbation.

L'exécution de DELETE dans une base de données de production est une opération à haut risque. Le ticket doit être approuvé par l'approbateur spécifié dans le modèle d'approbation avant de pouvoir être exécuté.

Blocage des instructions TRUNCATE dans la base de données de production

TRUNCATE supprime toutes les lignes d'une table et ne peut pas être annulée. Pour éviter toute perte accidentelle de données en production, configurez une règle de sécurité qui bloque les instructions TRUNCATE, à la fois dans la console SQL et via les tickets.

Étape 1 : Modification de la règle de sécurité pour bloquer TRUNCATE

Connectez-vous à la console DMSconsole DMS en tant qu'administrateur DMS.
Placez le pointeur sur l'icône située dans le coin supérieur gauche, puis choisissez All Features > Security and disaster recovery (DBS) > Security Rules.

En mode normal, choisissez Security and disaster recovery (DBS) > Security Rules dans la barre de navigation supérieure.
Sur la page Security Rules, repérez les règles de la base de données de production POC et cliquez sur Edit dans la colonne Actions.
Dans le volet de navigation de gauche, cliquez sur SQL Correct. Définissez Checkpoints sur SQL execution rules.
Repérez la règle Allow TRUNCATE to be executed directly in the SQL console et cliquez sur Edit dans la colonne Actions.
Renommez la règle en Forbid TRUNCATE statements. Remplacez le langage spécifique au domaine (DSL) existant par le suivant et cliquez sur Submit :

Ce DSL bloque TRUNCATE à la fois dans la console SQL et via les tickets. Pour plus d'informations sur la syntaxe DSL, consultez la rubrique Syntaxe DSL pour les règles de sécurité .
```
if
    @fac.sql_type in
      ['TRUNCATE']
then
    @act.forbid_execute
end
```
Repérez la règle TRUNCATE cannot be executed directly in the SQL console. It must be executed as a ticket. et cliquez sur Enable dans la colonne Actions. Cliquez sur OK pour confirmer.

Étape 2 : Vérification de la règle dans la console SQL

Dans la console DMS, recherchez l'instance poc_prod.
Dans l'onglet SQLConsole, exécutez l'instruction suivante :
```
TRUNCATE TABLE `data_modify`;
```
Execution Failed s'affiche. La règle de sécurité bloque l'instruction TRUNCATE.

Étape 3 : Vérification de la règle pour les soumissions de tickets

Soumettez un ticket de modification de données avec l'instruction SQL suivante (consultez Soumission d'un ticket pour une modification standard des données) :

TRUNCATE TABLE `data_modify`;

Après avoir soumis le ticket, vérifiez les résultats de la pré-vérification. Si celle-ci échoue, la règle bloque également TRUNCATE via le flux de travail des tickets.

Étapes suivantes

Syntaxe DSL pour les règles de sécurité — rédigez des règles personnalisées pour vos propres politiques de gouvernance SQL
Gestion des règles de sécurité — configurez, activez et désactivez les règles sur les instances de base de données
Conception de schéma — créez et gérez des schémas de table sans soumettre de tickets DDL