データ変更の方法 - Data Management - Alibaba Cloud ドキュメントセンター

Data Management (DMS) では、ガードレールなしでデータ変更を行うとリスクが高まります。本番環境での DELETE ステートメントの実行ミスや、誤った TRUNCATE の実行は、ロールバックできない重大な障害を引き起こす可能性があります。DMS では、セキュリティルールによって、SQLConsole で直接実行可能な SQL ステートメント、チケット承認を経て実行する必要がある SQL ステートメント、および完全にブロックされる SQL ステートメントを制御します。本トピックでは、セキュリティコラボレーションモードにおける 4 つの代表的なシナリオについて説明し、各環境に最適なガバナンスポリシーを設定する方法をご案内します。

仕組み

DMS におけるすべてのデータ変更は、以下のライフサイクルに従います：

ステージ	説明
SQL の記述	SQLConsole に SQL ステートメントを入力するか、チケットに `.sql`、`.txt`、または `.zip` ファイルを添付します。
事前チェック	DMS は、実行前にセキュリティルールに基づいて SQL を自動的に検証します。
承認	セキュリティルールでチケット提出が必須と定義されている場合、変更は指定された承認者（デフォルト：DBA）に送信されます。
実行	即時実行またはスケジュール実行を選択できます。また、データ操作言語（DML）ステートメントを単一トランザクションで実行することも可能です。
バックアップとロールバック	DMS は、`UPDATE` および `DELETE` 操作に対してバックアップ文を生成し、必要に応じてロールバックを可能にします。

各ステージにおける動作は、各データベースインスタンスに紐付けられた構成可能なセキュリティルール（ポリシー）によって制御されます。

前提条件

開始する前に、以下の条件を満たしていることを確認してください。

DMS 管理者アカウント、またはデータ変更チケットを送信する権限があること
セキュリティコラボレーションモードで DMS に登録済みの poc_prod および poc_dev データベースインスタンス
両方のデータベースに data_modify テーブルが作成済みであること

data_modify テーブルの作成

本トピックの 4 つの例では、DMS のスキーマ設計機能を使用して data_modify テーブルを作成しました。この DDL ステートメントは、開発用データベースではチケットを経ずに SQLConsole で直接実行可能です。

CREATE TABLE `data_modify` (
 `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT COMMENT 'プライマリキー',
 `name` varchar(256) NOT NULL COMMENT '氏名',
 `phone` varchar(32) DEFAULT NULL COMMENT '電話番号',
 `sex` varchar(32) DEFAULT NULL COMMENT '性別',
 `email` varchar(256) DEFAULT NULL COMMENT 'メールアドレス',
 `remarks` varchar(1024) DEFAULT NULL COMMENT '備考',
 PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='個人情報';

4 つのシナリオで使用されるセキュリティルールセットは以下のとおりです。

データベースインスタンス	セキュリティルールセット
`poc_dev`	POC 開発用データベース向けセキュリティルール
`poc_prod`	POC 本番用データベース向けセキュリティルール

定期的なデータ変更のためのチケット送信

本シナリオでは、data_modify テーブルへの行挿入を、poc_prod データベースでデータ変更チケットを送信して実行します。

DMS コンソール V5.0DMS コンソール V5.0 にログインします。
左上隅のアイコンにポインターを合わせ、全機能 > データベース開発 > データ変更 > 通常のデータ変更 を選択します。
通常モードでは、上部ナビゲーションバーから データベース開発 > データ変更 > 通常のデータ変更 を選択します。

チケットのパラメーターを入力します。主なパラメーターは以下のとおりです。

パラメーター	説明
SQL テキスト	実行する SQL ステートメント。複数のステートメントはセミコロン (`;`) で区切ります。
添付ファイル	`.txt`、`.zip`、または `.sql` ファイルをアップロードします。最大ファイルサイズ：15 MB。

送信をクリックします。DMS が自動的に事前チェックを実行します。事前チェックが失敗した場合は、画面の指示に従って SQL を修正し、再度送信してください。
事前チェックが成功した後、承認依頼 をクリックし、確認メッセージで OK をクリックします。
データ変更チケットは、デフォルトで DBA によって承認されます。デフォルトの承認テンプレートを変更するには、「デフォルトの承認テンプレートを変更する」セクションをご参照ください（SQL Correct トピック）。

チケットが承認された後、変更の実行 をクリックします。タスク設定 ダイアログボックスで実行パラメーターを設定し、実行の確認 をクリックします。

申請ステップで 実行方法 を 監査承認後に自動実行 に設定した場合、このステップは自動的にスキップされます。一時停止中のタスクを再開すると、中断した位置から実行が再開されます。

パラメーター	説明
実行戦略	即時実行（デフォルト）：チケットが確認されるとすぐに実行されます。スケジュール実行：指定した時刻に実行されます。
単一トランザクションとして送信を有効化	デフォルト：無効。有効：DML ステートメントのいずれかが失敗した場合、トランザクション内のすべての DML ステートメントがロールバックされます（DDL ステートメントはロールバックできません）。無効：各ステートメントは独立して実行され、失敗時に実行が停止しますが、それ以前のステートメントはロールバックされません。
バックアップを有効化	デフォルト：有効。DMS は `UPDATE` および `DELETE` ステートメントに対してバックアップ文を生成します。データベース固有の詳細については、「バックアップ対応状況」をご参照ください。

（任意）実行完了後、poc_prod の SQLConsole を開き、結果を確認します。

バックアップ対応状況

バックアップは UPDATE および DELETE ステートメントのみに対応しています。INSERT ステートメントおよび DDL ステートメントはバックアップされません。

データベース種別	バックアップステートメント生成済み	備考
MySQL、MariaDB	`REPLACE INTO`	ApsaraDB RDS for MySQL、PolarDB for MySQL、PolarDB-X、およびセルフマネージド MySQL を含む
その他のサポート対象データベース	`INSERT`	—
MongoDB、Redis	非対応	—

開発用データベースで DML ステートメントを SQLConsole で直接実行可能にする

デフォルトでは、DMS のセキュリティルールにより、すべての DML ステートメントはチケットを経る必要があります。しかし、開発用データベースでは、このプロセスが反復開発の速度を遅くします。セキュリティルールを構成して、開発者が毎回チケットを送信せずに SQLConsole で DML ステートメントを直接実行できるようにします。

ステップ 1：poc_dev のセキュリティルールを更新

DMS コンソール V5.0DMS コンソール V5.0 に DMS 管理者としてログインします。
左上隅のアイコンにポインターを合わせ、全機能 > セキュリティおよびディザスタリカバリ（DBS） > セキュリティルール を選択します。
通常モードでは、上部ナビゲーションバーから セキュリティおよびディザスタリカバリ（DBS） > セキュリティルール を選択します。
左上隅のアイコンにポインターを合わせ、全機能 > セキュリティおよびディザスタリカバリ（DBS） > セキュリティルール を選択します。

説明
通常モードで DMS コンソールを使用する場合、上部ナビゲーションバーから セキュリティおよびディザスタリカバリ（DBS） > セキュリティルール を選択します。
左上隅のアイコンにポインターを合わせ、全機能 > セキュリティおよびディザスタリカバリ（DBS） > セキュリティルール を選択します。

説明
通常モードで DMS コンソールを使用する場合、上部ナビゲーションバーから セキュリティおよびディザスタリカバリ（DBS） > セキュリティルール を選択します。
左上隅のアイコンにポインターを合わせ、全機能 > セキュリティおよびディザスタリカバリ（DBS） > セキュリティルール を選択します。

説明
通常モードで DMS コンソールを使用する場合、上部ナビゲーションバーから セキュリティおよびディザスタリカバリ（DBS） > セキュリティルール を選択します。
セキュリティルール ページで、POC 開発用データベースのルールを見つけ、編集をクリックします（操作列）。
左側ナビゲーションウィンドウで SQL Correct をクリックします。チェックポイント を SQL 実行ルール に設定します。
すべての DML を SQLConsole で直接実行可能にする を有効化し、すべての DML はチケット経由で実行する必要がある を無効化します。

ステップ 2：ルール変更の検証

DMS コンソールの左上隅で、poc_dev インスタンスを検索します。

SQLConsole タブで、以下の INSERT ステートメントを実行します。

INSERT INTO data_modify (name, phone, sex) VALUES ('dms_a', '19000001','男性');
INSERT INTO data_modify (name, phone, sex) VALUES ('dms_b', '19000002','女性');
INSERT INTO data_modify (name, phone, sex) VALUES ('dms_c', '19000003','男性');

実行確認 ダイアログボックスで実行をクリックします。実行済み というメッセージが表示された場合、ルール変更が正しく適用されています。

本番データベースにおける高リスク SQL に対するチケット承認の要請

DELETE などの一部の SQL ステートメントは、本番環境において重大なリスクを伴います。セキュリティルールを構成して、DELETE を高リスク操作として識別し、専用の承認プロセスを経由させるようにします。

ステップ 1：承認プロセスの作成

DMS コンソールDMS コンソールに DMS 管理者としてログインします。
左上隅のアイコンにポインターを合わせ、全機能 > セキュリティおよびディザスタリカバリ（DBS） > 承認プロセス を選択します。
通常モードでは、上部ナビゲーションバーから セキュリティおよびディザスタリカバリ（DBS） > 承認プロセス を選択します。
承認テンプレートの作成 をクリックし、承認ノードを構成します。ノードは昇順で追加します（ノード 1 が最初の承認者、ノード 2 が 2 番目の承認者、以降同様）。
送信をクリックします。

ステップ 2：リスク識別ルールの構成

左上隅のアイコンにポインターを合わせ、全機能 > セキュリティおよびディザスタリカバリ（DBS） > セキュリティルール を選択します。
通常モードでは、上部ナビゲーションバーから セキュリティおよびディザスタリカバリ（DBS） > セキュリティルール を選択します。
セキュリティルール ページで、POC 本番用データベースのルールを見つけ、編集をクリックします（操作列）。
左側ナビゲーションウィンドウで SQL Correct をクリックします。チェックポイント を リスク識別ルール に設定し、ルールの作成 をクリックします。
ルールの作成 - SQL Correct ダイアログボックスで、以下のパラメーターを設定します。
パラメーター 値
ルール名 本番環境：DELETE ステートメントの実行は高リスク操作です
ルール DSL 以下の DSL コードを参照
```
if
    @fac.env_type in ['product','pre']
    and
    @fac.sql_type in
    [ 'DELETE']
then
    @act.mark_risk 'high' '高リスク SQL ステートメント：本番環境における DELETE'
end
```
送信をクリックします。
本番環境：DELETE ステートメントの実行は高リスク操作です ルールを見つけ、有効化 をクリックします（操作列）。確認メッセージで OK をクリックします。このルールは即時に有効化され、すべての DELETE ステートメントが高リスク操作として識別されます。

パラメーター	値
ルール名	`本番環境：DELETE ステートメントの実行は高リスク操作です`
ルール DSL	以下の DSL コードを参照

ステップ 3：承認プロセスとリスク承認ルールの関連付け

チェックポイント を リスク承認ルール に設定します。高リスク承認プロセス ルールを見つけ、編集をクリックします（操作列）。
ルールの変更 - SQL Correct ダイアログボックスで、ルール DSL フィールド内のテンプレート ID を、ステップ 1 で作成した承認テンプレートの ID に置き換えます。送信をクリックします。
高リスク承認プロセス ルールを見つけ、有効化 をクリックします。OK をクリックして確認します。

ステップ 4：ルールの検証

DMS コンソールで、poc_prod インスタンスを検索します。
SQLConsole タブで、以下のステートメントを実行します。
```
DELETE FROM data_modify WHERE id = 1;
```
実行履歴エリアにセキュリティルールによるエラーメッセージが表示された場合、ルールが正しく機能しています。データ変更の申請 をクリックしてチケットを送信し、承認プロセスを経てください。
本番データベースにおける DELETE の実行は高リスク操作です。チケットは、承認テンプレートで指定された承認者による承認を受けて初めて実行可能になります。

本番データベースにおける TRUNCATE ステートメントのブロック

TRUNCATE はテーブル内のすべての行を削除し、ロールバックできません。本番環境における誤ったデータ損失を防ぐため、TRUNCATE ステートメントを SQLConsole およびチケットの両方の経路でブロックするセキュリティルールを構成します。

ステップ 1：TRUNCATE をブロックするセキュリティルールの変更

DMS コンソールDMS コンソールに DMS 管理者としてログインします。
左上隅のアイコンにポインターを合わせ、全機能 > セキュリティおよびディザスタリカバリ（DBS） > セキュリティルール を選択します。
通常モードでは、上部ナビゲーションバーから セキュリティおよびディザスタリカバリ（DBS） > セキュリティルール を選択します。
セキュリティルール ページで、POC 本番用データベースのルールを見つけ、編集をクリックします（操作列）。
左側ナビゲーションウィンドウで SQL Correct をクリックします。チェックポイント を SQL 実行ルール に設定します。
TRUNCATE を SQL コンソールで直接実行可能にする ルールを見つけ、編集をクリックします（操作列）。
ルール名を TRUNCATE ステートメントの禁止 に変更します。既存のドメイン特化言語（DSL）を以下の内容に置き換え、送信をクリックします。
この DSL は、SQLConsole およびチケットの両方で TRUNCATE をブロックします。DSL 構文の詳細については、「セキュリティルールの DSL 構文」をご参照ください。
```
if
    @fac.sql_type in
      ['TRUNCATE']
then
    @act.forbid_execute
end
```
TRUNCATE は SQL コンソールで直接実行できません。チケット経由でのみ実行可能です。 ルールを見つけ、有効化 をクリックします（操作列）。確認メッセージで OK をクリックします。

ステップ 2：SQLConsole におけるルールの検証

DMS コンソールで、poc_prod インスタンスを検索します。
SQLConsole タブで、以下のステートメントを実行します。
```
TRUNCATE TABLE `data_modify`;
```
実行失敗 が表示されます。セキュリティルールが TRUNCATE ステートメントをブロックしています。

ステップ 3：チケット送信におけるルールの検証

以下の SQL ステートメントを含むデータ変更チケットを送信します（「定期的なデータ変更のためのチケット送信」を参照）。

TRUNCATE TABLE `data_modify`;

チケットを送信した後、事前チェックの結果を確認します。事前チェックが失敗した場合、ルールはチケットワークフローを通じた TRUNCATE の実行もブロックしています。

次のステップ

セキュリティルールの DSL 構文 — 自社の SQL ガバナンスポリシーに合わせたカスタムルールを作成します
セキュリティルールの管理 — データベースインスタンス全体でルールの設定、有効化、および無効化を行います
スキーマ設計 — DDL チケットを送信せずにテーブルスキーマを作成および管理します