Зашифровать данные в базе данных

[zVlad]

В Active Directory хранится информация о пользователях имеющих доступ в Enterprise network. Для того M$ её и создала. Кастомеры не являются пользователями сети, потому информация о них действительно хранится в БД. Что по вашему тут неправильного?

MS создал недоразвитое решение. Как всегда. На МФ все "пользователи", и мой аккаунт - RACF Special, у которого все возможности по умолчанию и пользователи клиента хранятся в одном месте - базе данных RACF, или, если хотишь, Active Directory в теминологии MS. Это позволяет избежать проблему нашего друга, топикстартера. Аккунты RACF, в зависимости от того где они могут быть использоиваны - в каких приложениях -, могут иметь или не иметь разнообразные "сегменты". Например для работы в Юникс, или NetView. Если аккоунт не имеет сегмента Юникс, то Юникс ему недоступен. Простейшие аккаунты клиента не имеют никаких сегментов и существуют только для верификации пароля.
Понятно что скоммуниздить RACF базу данных невозможно. Но даже если скоммуниздить то восстановить пароли невозможно. Думаю не надо обьяснять почему. Тоже, полагаю, относится к Active Directory. Странно почему кастомеры, по Вашему, не могут быть там. Кстати, кастомеры нашего клиента точно имеют аккаунты в Active Directory.
Кроме Active Directory имеются разные там LDAP-ы. Думаю что ситуация топикстартера надумана.

[Mark]

у MSSQL на 200% есть возможность шифрования базы налету.

так я же писал, что ихние DBA сидят в Индии и тупые как пробки (те технари и менеджры что в Англии сидят тоже дебилы еще те), они не желают учить это и просто говорят своему начальству что this is not secure enough.

А давайте предложим вашему клиенту контракт по внедрению TDE если интересно пишите в личку


Sent from my iPhone using Tapatalk

А что конкретно этот контракт будет подразумевать?

Вкратце - Transparent Database Encryption (TDE) implementation:
- Encrypted database storage setup including certificates/wallets configuration
- Data migration into encrypted storage/tablespace with zero downtime using online redefinition
- Routine maintenance procedures adjustments (startup/shutdown, backups. certificates rotation)
Если вас серьезно интересует proposal - пишите в личку
p.s. Это так же можно объеденить с внедрение Oracle Advanced Compression (ACO) чтоб ужать данные (в сренднем в 2-4 раза жмутся без performance degradation)
p.p.s. TDE and ACO требуют дополнительного лицензирования. Если у клиента не куплено то надо покупать

[Mark]

Бля... просто нет слов!!! Я уже теперь борюсь не этим гребаным барклаем, а со своим начальником (и менеджером, который тоже девелопер).

Я им говорю, что RSA НЕ предназначен для шифрования больших объемов данных. Просто физически это невозможно, для этого есть тот же AES например. У асимметричных и симметричных алгоритмов разные цели абсолютно и не надо пытаться применить один алгоритм, если у него другая цель. Мне в ответ "ну вот мы пообещали RSA и барклай согласился и надо делать RSA" Так может прежде, чем предлагать что то, надо сначала понять а подойдет ли это решение? Разумно ли его пользовать? я уже устал присылать им статьи в инете..

может кто подскажет ссылку на статью, которая ясно и четко покажет для чего нужен RSA и для чего AES...

Если мы все еще об Oracle TDE то оно не поддерживает RSA. Только DES and AES:
https://docs.oracle.com/database/121/AS ... ASOAG10117

[Mark]

В Active Directory хранится информация о пользователях имеющих доступ в Enterprise network. Для того M$ её и создала. Кастомеры не являются пользователями сети, потому информация о них действительно хранится в БД. Что по вашему тут неправильного?

ну можно создать внешний домен для кастомеров - и используя directory services законнектить все к базе (Oracle EUS for example). но в принципе и хранение app users в базе это не криминал - просто хеш вместо plain text password - это как бы закон!

[valchkou]

согласен с некоторыми ораторами, простое работающее решение использовать vault + AES.
Простое не значит плохое или недостаточно безопасное!
Вопрос тут в другом, как защитить сам VAULT от несанкционированного доступа и от потери самого вольта.

Вариант без вольта тоже сработает, это установка сертификата на саму машину где запущена прога.
Но и тут есть подводные камни. Как управлять такими сертификатами?

Короче простого решения нет, если нет системы и процесса управления ключами/секретами/сертификатами.
Но если есть, то реализовать фичу просто.

[alex_127]

интересно может будет почитать про https://docs.microsoft.com/en-us/sql/re ... rver-ver15
одной строчкой: engine never sees unencrypted data. по зашифрованному ключу можно делать индех. и он сортирован (range scans). но больше места займет.

[Flash-04]

В Active Directory хранится информация о пользователях имеющих доступ в Enterprise network. Для того M$ её и создала. Кастомеры не являются пользователями сети, потому информация о них действительно хранится в БД. Что по вашему тут неправильного?

ну можно создать внешний домен для кастомеров - и используя directory services законнектить все к базе (Oracle EUS for example). но в принципе и хранение app users в базе это не криминал - просто хеш вместо plain text password - это как бы закон!

в принципе можно, да.

[Mark]

согласен с некоторыми ораторами, простое работающее решение использовать vault + AES.
Простое не значит плохое или недостаточно безопасное!
Вопрос тут в другом, как защитить сам VAULT от несанкционированного доступа и от потери самого вольта.

Вариант без вольта тоже сработает, это установка сертификата на саму машину где запущена прога.
Но и тут есть подводные камни. Как управлять такими сертификатами?

Короче простого решения нет, если нет системы и процесса управления ключами/секретами/сертификатами.
Но если есть, то реализовать фичу просто.

а чем вас orapki не устраивает как тулза - у автора ведь Oracle DB? Зачем выдумывать велосипед? Есть более продвинутые (и дорогие) решения как тот же Orale Key Vault или claud-based like Azure Key Vault.

[valchkou]

согласен с некоторыми ораторами, простое работающее решение использовать vault + AES.
Простое не значит плохое или недостаточно безопасное!
Вопрос тут в другом, как защитить сам VAULT от несанкционированного доступа и от потери самого вольта.

Вариант без вольта тоже сработает, это установка сертификата на саму машину где запущена прога.
Но и тут есть подводные камни. Как управлять такими сертификатами?

Короче простого решения нет, если нет системы и процесса управления ключами/секретами/сертификатами.
Но если есть, то реализовать фичу просто.

а чем вас orapki не устраивает как тулза - у автора ведь Oracle DB? Зачем выдумывать велосипед? Есть более продвинутые (и дорогие) решения как тот же Orale Key Vault или claud-based like Azure Key Vault.

меня устраивает , более того я сторонник готовых решений.
вопрос в другом, почему компания стартера до сих пор этим не пользуется, при том что в клиентах у них как минимум банк

[Mark]

Если я правильно понимаю в банке собственные DBAs которые просто не знают или не хотят особо шевелится. А компания топик-стартера предполагаю никаких прав на базу и инфраструктуру не имеет.

[shadow7256]

Если я правильно понимаю в банке собственные DBAs которые просто не знают или не хотят особо шевелится. А компания топик-стартера предполагаю никаких прав на базу и инфраструктуру не имеет.

Всё верно по всем пунктам. Банк согласился на AES шифрование. Ну пусть радуются.

[shadow7256]

Гребаный Барклай теперь пишет вот что:

- Data would be protected by AES-256.
- The key would be stored locally on the server in Windows Key Store (CNG)

Поправьте меня спецы, но CNG используется для хранения public and private keys при использовании asymmetric encryption или digital signatures.

Разве можно в CNG хранить symmetric key and IV, которые используются при AES-256 ???

[shadow7256]

у автора ведь Oracle DB?

у них SQL Server.

[Oleg-NY]

Гребаный Барклай теперь пишет вот что:

- Data would be protected by AES-256.
- The key would be stored locally on the server in Windows Key Store (CNG)

Поправьте меня спецы, но CNG используется для хранения public and private keys при использовании asymmetric encryption или digital signatures.

Разве можно в CNG хранить symmetric key and IV, которые используются при AES-256 ???

Совсем не обязательно там хранить сам актуальный AES-256 key, т.к. они могут и должны быть разными (по аналогии с тем, как это происходит в TLS, например). Все зависит от того как и что вы собираетесь шифровать, но всякие encrypted blob сами в себе содержат оный симметричный ключ в зашифрованном виде с помощью мастер-ключа. Вот мастер-ключ и храните в CNG или где-нибудь еще... Данный подход еще и аппаратно реализован много где так, что можно будет разгрузить основной проц или вынести шифрование в отдельный блок для пущей секретности так сказать! )) Плюс в данном виде можно еще и доп. ключ/пароль от пользоателя подмешивать для авторизации доступа и т.д.

[shadow7256]

Гребаный Барклай теперь пишет вот что:

- Data would be protected by AES-256.
- The key would be stored locally on the server in Windows Key Store (CNG)

Поправьте меня спецы, но CNG используется для хранения public and private keys при использовании asymmetric encryption или digital signatures.

Разве можно в CNG хранить symmetric key and IV, которые используются при AES-256 ???

Совсем не обязательно там хранить сам актуальный AES-256 key, т.к. они могут и должны быть разными (по аналогии с тем, как это происходит в TLS, например). Все зависит от того как и что вы собираетесь шифровать, но всякие encrypted blob сами в себе содержат оный симметричный ключ в зашифрованном виде с помощью мастер-ключа. Вот мастер-ключ и храните в CNG или где-нибудь еще... Данный подход еще и аппаратно реализован много где так, что можно будет разгрузить основной проц или вынести шифрование в отдельный блок для пущей секретности так сказать! )) Плюс в данном виде можно еще и доп. ключ/пароль от пользоателя подмешивать для авторизации доступа и т.д.

Задача конкретная.. где хранить symmetric key and Initialization vector? В CNG невозможно это сделать, так как CNG используется для asymmetric keys.