Создание столбцов с зашифрованными данными
Создадим таблицу для работы, для определенности в схеме SCOTT: CREATE TABLEclosed ( a VARCHAR2 ( 10 ) , b VARCHAR2 ( 10 ) , c VARCHAR2 ( 10 ) ); INSERT INTO closed VALUES ( 'normal1', 'secret', 'normal1' ); INSERT INTO closed VALUES ( 'normal2', 'secret', 'normal2' ); COMMIT;
Для начала рассмотрим обычное хранение строк. Выдадим в SQL*Plus: SQL> SELECT 2 DBMS_ROWID.ROWID_RELATIVE_FNO ( ROWID ) file# 3 , DBMS_ROWID.ROWID_BLOCK_NUMBER ( ROWID ) block# 4 FROM closed SQL> ;
FILE# BLOCK# ---------- ---------- 4 4
597 597
Обе короткие строки попали в один блок на диске. В моем случае это блок № 597 в файле № 4. Подставим полученные значения в команду, которую выдадим от имени SYS: ALTER SYSTEM DUMP DATAFILE 4 BLOCK 597;
В трассировочном файле серверного процесса, обслуживающего сеанс, появилась примерно следующая информация: ... EEF7DB0 32656662 5F353633 72756F53 6F546563 [bfe2365_SourceTo] EEF7DC0 4C4D5448 766E6F43 0703012C 6D726F6E [HTMLConv,...norm] EEF7DD0 06326C61 72636573 6E077465 616D726F [al2.secret.norma] EEF7DE0 012C326C 6F6E0703 6C616D72 65730631 [l2,...normal1.se] EEF7DF0 74657263 726F6E07 316C616D A1810604 [cret.normal1....] Block header dump: 0x01000255 ...
Пока еще не засекреченные значения выделены серым фоном. Зашифруем их в блоке: ALTER TABLE closed MODIFY ( b ENCRYPT );
Это можно сделать только при открытом бумажнике. Вот что получим в файле трассировки серверного процесса: ... EEF7D30 0B6A7807 12380B13 0703022C 6D726F6E [.xj...8.,...norm] EEF7D40 34326C61 0E8464A4 1304CAAE E1116635 [al24.d......5f..] EEF7D50 5B06C8CD C3AABA4A 8B4EA144 CE2B4987 [...[J...D.N..I+.] EEF7D60 EB2DEBB1 E97EB0C5 CDCA2CDB 99AC18E9 [..-...~..,......] EEF7D70 52E1F415 CA85201C 726F6E07 326C616D [...R. ...normal2] EEF7D80 0703022C 6D726F6E 34316C61 1F21C866 [,...normal14f.!.] EEF7D90 D765D462 EC2D8A33 8DF8F328 EC42E142 [b.e.3.-.(...B.B.] EEF7DA0 CB3EEB72 A36909CE A28C845E 0F04567C [r.>...i.^...|V..] EEF7DB0 3C74BEC5 8F3EAEA8 B3612F6E 6009C40C [..t.n/a....`] EEF7DC0 726F6E07 316C616D 0703002C 6D726F6E [.normal1,...norm] EEF7DD0 06326C61 72636573 6E077465 616D726F [al2.secret.norma] EEF7DE0 002C326C 6F6E0703 6C616D72 65730631 [l2,...normal1.se] EEF7DF0 74657263 726F6E07 316C616D A9BB0601 [cret.normal1....] Block header dump: 0x01000255 ...
Значения двух слов 'secret' в блоке действительно оказались зашифрованы (и стали занимать больше места). Обратите внимание, что шифрование ранее занесенных данных Oracle отрабатывает алгоритмом команды UPDATE, который допускает временное сохранение в блоке старых данных, на радость злоумышленникам (в SQL Server то же самое, если верить интернету).
Выдача значений не раскроет того обстоятельства, что в блоке они хранятся зашифровано: SQL> SELECT * FROM closed; A B C ---------- ---------- ---------- normal1 secret normal1 normal2 secret normal2
Упражнение. Закройте бумажник командой, приведенной выше, и убедитесь, что в этом случае Oracle не сможет показать значение зашифрованного поля B таблицы CLOSED. Откройте бумажник снова для продолжения работы.
Бросается в глаза, что одно и то же значение ('secret') дало разный результат шифрования. Так произошло потому, что для дополнительной защиты Oracle перед шифрованием приписывает к значению случайную последовательность байтов, так называемую «привязку» (salt). Это препятствует расшифровке, и даже лишает возможности злоумышленника понять, что в разных полях исходно были одинаковые значения. С
другой стороны (а) «привязка» замедляет обработку данных и (б) препятствует созданию (древовидного) индекса на шифруемый столбец. Последнее вызвано тем, что значения полей индексируемого столбца помещаются в структуру индекса, и поскольку равные исходные значения будут давать разные шифрованные, индекс не сможет отрабатывать поиск по диапазону, то есть обесценится. Вот Oracle это и запрещает: SQL> CREATE INDEX closed_b ON closed ( b ); CREATE INDEX closed_b ON closed ( b ) * ERROR at line 1: ORA-28338: cannot encrypt indexed column(s) with salt
От применения привязки можно отказаться: ALTER TABLE closed MODIFY ( b ENCRYPT NO SALT );
Вот пример последовавшего результата из трассировочного файла: ... EEF7CC0 02C10265 06C102FF 0703012C 6D726F6E [e.......,...norm] EEF7CD0 24326C61 C565F542 45F6CA9D C4516D27 [al2$B.e....E'mQ.] EEF7CE0 902DEF69 C655685B 00844987 08803082 [i.-.[hU..I...0..] EEF7CF0 A6106E22 45F862E5 726F6E07 326C616D ["n...b.E.normal2] EEF7D00 0703012C 6D726F6E 24316C61 C565F542 [,...normal1$B.e.] EEF7D10 45F6CA9D C4516D27 902DEF69 C655685B [...E'mQ.i.-.[hU.] EEF7D20 00844987 08803082 A6106E22 45F862E5 [.I...0.."n...b.E] EEF7D30 726F6E07 316C616D 0703002C 6D726F6E [.normal1,...norm] EEF7D40 34326C61 0E8464A4 1304CAAE E1116635 [al24.d......5f..] EEF7D50 5B06C8CD C3AABA4A 8B4EA144 CE2B4987 [...[J...D.N..I+.] EEF7D60 EB2DEBB1 E97EB0C5 CDCA2CDB 99AC18E9 [..-...~..,......] EEF7D70 52E1F415 CA85201C 726F6E07 326C616D [...R. ...normal2] EEF7D80 0703022C 6D726F6E 34316C61 1F21C866 [,...normal14f.!.] EEF7D90 D765D462 EC2D8A33 8DF8F328 EC42E142 [b.e.3.-.(...B.B.] EEF7DA0 CB3EEB72 A36909CE A28C845E 0F04567C [r.>...i.^...|V..] EEF7DB0 3C74BEC5 8F3EAEA8 B3612F6E 6009C40C [..t.n/a....`] EEF7DC0 726F6E07 316C616D 0703002C 6D726F6E [.normal1,...norm] EEF7DD0 06326C61 72636573 6E077465 616D726F [al2.secret.norma] EEF7DE0 002C326C 6F6E0703 6C616D72 65730631 [l2,...normal1.se] EEF7DF0 74657263 726F6E07 316C616D A9BB0601 [cret.normal1....] Block header dump: 0x01000255 ...
Теперь два верхних отмеченных серым фоном значения в блоке стали одинаковыми.
Упражнение. Проверить открывшийся шанс завести индекс по полю B таблицы CLOSED.
