Статья Риски автоматического шифрования полей MySQL через AES_ENCRYPT

[devqp]

Процедура ниже автоматически шифрует все текстовые поля в базе данных MySQL с использованием AES_ENCRYPT и преобразует результат в HEX:

DELIMITER $$

CREATE PROCEDURE EncryptAllFields()
BEGIN
  DECLARE done INT DEFAULT FALSE;
  DECLARE aTable, aColumn CHAR(255);
  DECLARE cur1 CURSOR FOR 
    SELECT TABLE_NAME, COLUMN_NAME 
    FROM INFORMATION_SCHEMA.COLUMNS 
    WHERE TABLE_SCHEMA = 'dbname' 
      AND DATA_TYPE IN ('varchar', 'text');
  
  DECLARE CONTINUE HANDLER FOR NOT FOUND SET done = TRUE;
  
  OPEN cur1;
  read_loop: LOOP
    FETCH cur1 INTO aTable, aColumn;
    IF done THEN
      LEAVE read_loop;
    END IF;
    
    SET @s = CONCAT(
      'UPDATE `', aTable, 
      '` SET `', aColumn, 
      '` = HEX(AES_ENCRYPT(`', aColumn, '`, "secret_key")) WHERE `', 
      aColumn, '` IS NOT NULL;'
    );
    PREPARE stmt FROM @s;
    EXECUTE stmt;
    DEALLOCATE PREPARE stmt;
  END LOOP;
  CLOSE cur1;
END$$

DELIMITER ;

Ключевые риски такого подхода:
1. MySQL по умолчанию логирует все запросы через general_log и binary_log. Процедура и ключ "secret_key" могут быть обнаружены в логах.
2. Шифрование не затрагивает резервные копии БД. Администраторы легко восстановят данные из бэкапов.
3. Ключ хранится в открытом виде внутри процедуры. При наличии привилегии SELECT на mysql.proc злоумышленник может извлечь его.
4. HEX-кодирование увеличивает объем данных на 60-100%, что может вызвать переполнение полей.

Вывод: Данный метод не обеспечивает безопасность для злонамеренных целей. Логирование, бэкапы и открытое хранение ключа делают шифрование неэффективным и легко обратимым.