Если есть желание голосом пообщаться то кидайте номер в личку - созвонимся. Я с подобными проблемами сталкиваться не однократно и всякие аудиты проходил
![Wink ;)](./images/smilies/wink.gif)
Данные меняются через UI (через Веб приложение), оно же их и читает и сохраняет обратно в базе. Также есть виндовый сервис, который только читает данные (вот он собственно и использует эти конфигурации, чтобы уже работать с серверами. UI это чисто чтобы менять конфигурацию, или создавать новые сервера).kostik78 wrote: ↑20 Dec 2020 21:01 Опять же если что то хорошего Вам насоветовать то надо знать структуру данных конфигурации. Как правило никто не криптует весь конфиг одним скопом - это глупо и реально создание видимости криптографии. Обычно внутри конфигурации какие то параметры или пароли нужно шифровать то бишь не больших размеров. Второй важный вопрос как конфигурация изменяеться. Например через UI или через change management system ну и так далее. Соотвественно варианты решения: public + private key для маленьких данных или комбинация public + private key + password для симитричного алгоритма. Так что просто так с нахрапу не вылет. Нужно смотреть что нужно защищать, как защищённые данные меняются и т.п.
Public + private key используется для того чтобы не было необходимости говорить людям симметричный пароль. Например: пароли в конфигах хранятся в зашифрованном виде при этом данный конфиг обслуживается разными людьми (разные группы и т.п.) если использовать только симметричный алгоритм тогда пароль известен всем и все могут читать у друг друга пароли, секреты и т.п. (дикоиптовать и скомуниздить) что является биг NO-NO для любого аудита (можно конечно проблему решить через административные меры но тогда создаётся bottle neck на определенных людей).shadow7256 wrote: ↑20 Dec 2020 21:10Данные меняются через UI (через Веб приложение), оно же их и читает и сохраняет обратно в базе. Также есть виндовый сервис, который только читает данные (вот он собственно и использует эти конфигурации, чтобы уже работать с серверами. UI это чисто чтобы менять конфигурацию, или создавать новые сервера).kostik78 wrote: ↑20 Dec 2020 21:01 Опять же если что то хорошего Вам насоветовать то надо знать структуру данных конфигурации. Как правило никто не криптует весь конфиг одним скопом - это глупо и реально создание видимости криптографии. Обычно внутри конфигурации какие то параметры или пароли нужно шифровать то бишь не больших размеров. Второй важный вопрос как конфигурация изменяеться. Например через UI или через change management system ну и так далее. Соотвественно варианты решения: public + private key для маленьких данных или комбинация public + private key + password для симитричного алгоритма. Так что просто так с нахрапу не вылет. Нужно смотреть что нужно защищать, как защищённые данные меняются и т.п.
Имя сервера, его протокол (SMTP. POP3, FTP, etc). еще несколько параметров они не шифруются и хранятся в таблице в простом виде. Шифруется именно та часть конфигурации, которая sensitive (Username, Password , какие то public/private certificates, Host, Timeout interval, etc).
я не пойму, чем хорошо public + private keys (asymmetric) в отличие от symmetric? В asymmetric столько ограничений, которых просто нет в symmetric, так нафига заморачиваться с этим asymmetric?
Через внутренний закрытый GIT репозиторий. Там лежат файлы с этими паролями, которые считываются в момент deployment'a и тут же удаляются. То есть эти файлы лежат не вместе со всеми сорцами, а сами по себе. Если используются контейнеры, то вообще песня.
Мы как раз так делали.
В момент деплоймента или при старте?Там лежат файлы с этими паролями, которые считываются в момент deployment'a и тут же удаляются.
Тут согласен. Мы Oracle использовали, там конкретные колонки по-моему шифровались. DBA что-то наколдовал, мы добавляли ключ/пароль - и все были довольны...То есть эти файлы лежат не вместе со всеми сорцами, а сами по себе. Если используются контейнеры, то вообще песня.
А вообще мож я чего не понимаю, сам с этим не работал вот вплотную (я сейчас занимаюсь как раз тем, чему ШБД учил), но не суть: у MSSQL на 200% есть возможность шифрования базы налету.
так я же писал, что ихние DBA сидят в Индии и тупые как пробки (те технари и менеджры что в Англии сидят тоже дебилы еще те), они не желают учить это и просто говорят своему начальству что this is not secure enough.
Да и фиг с ним! Если это VM или контейнер - постараться еще надо на этот хост (контейнер) зайти. Но тут-то речь об ином - как хранить, а не как вообще спрятать. Кстати, я не уверен, что можно прочитать /proc, если процесс работает от лица кастрированного юзера без shell'a типа "tomcat" или "mongo". Ну если ты не root, само собой.
Это надо не DBA спрашивать, а secuiry architects, которые на этом специализируются.shadow7256 wrote:так я же писал, что ихние DBA сидят в Индии и тупые как пробки (те технари и менеджры что в Англии сидят тоже дебилы еще те), они не желают учить это и просто говорят своему начальству что this is not secure enough.
спасибо, скачал
А давайте предложим вашему клиенту контракт по внедрению TDEshadow7256 wrote:так я же писал, что ихние DBA сидят в Индии и тупые как пробки (те технари и менеджры что в Англии сидят тоже дебилы еще те), они не желают учить это и просто говорят своему начальству что this is not secure enough.
А что конкретно этот контракт будет подразумевать?Mark wrote: ↑23 Dec 2020 12:58А давайте предложим вашему клиенту контракт по внедрению TDEshadow7256 wrote:так я же писал, что ихние DBA сидят в Индии и тупые как пробки (те технари и менеджры что в Англии сидят тоже дебилы еще те), они не желают учить это и просто говорят своему начальству что this is not secure enough.если интересно пишите в личку
Sent from my iPhone using Tapatalk
вы видимо ожидали своего рода cookbook для написания кода. Это не так. Прежде чем переходить к кодописательству нужно изучить как вся эта кухня работает. И вот да, "Боб и Алиса" - это уже как бы устоявшийся мем у криптографов. Насчет того, что там нет "applied" - отнюдь. Там как раз разбираются все эти нюансы насчет стойкости алгоритмов, где слабые места и т.п. В конце книги интересная сводка по известым алгоритмам.shadow7256 wrote: ↑25 Dec 2020 16:54Кстати начал "читать" Вашу книгу) почти пол книги пролистал - одни ссылки на Боба, Алису и других "участников"
вообщем немного разочаровала она. Одна теория и никакого applied cryptography. Для спецов по безопасности наверное супер будет
клиентов в Active Directory? вы ничего не попутали? им там не место
MS создал недоразвитое решение. Как всегда. На МФ все "пользователи", и мой аккаунт - RACF Special, у которого все возможности по умолчанию и пользователи клиента хранятся в одном месте - базе данных RACF, или, если хотишь, Active Directory в теминологии MS. Это позволяет избежать проблему нашего друга, топикстартера. Аккунты RACF, в зависимости от того где они могут быть использоиваны - в каких приложениях -, могут иметь или не иметь разнообразные "сегменты". Например для работы в Юникс, или NetView. Если аккоунт не имеет сегмента Юникс, то Юникс ему недоступен. Простейшие аккаунты клиента не имеют никаких сегментов и существуют только для верификации пароля.
Вкратце - Transparent Database Encryption (TDE) implementation:shadow7256 wrote: ↑25 Dec 2020 16:55А что конкретно этот контракт будет подразумевать?Mark wrote: ↑23 Dec 2020 12:58А давайте предложим вашему клиенту контракт по внедрению TDEshadow7256 wrote:так я же писал, что ихние DBA сидят в Индии и тупые как пробки (те технари и менеджры что в Англии сидят тоже дебилы еще те), они не желают учить это и просто говорят своему начальству что this is not secure enough.если интересно пишите в личку
Sent from my iPhone using Tapatalk
Если мы все еще об Oracle TDE то оно не поддерживает RSA. Только DES and AES:shadow7256 wrote: ↑22 Dec 2020 19:19 Бля... просто нет слов!!! Я уже теперь борюсь не этим гребаным барклаем, а со своим начальником (и менеджером, который тоже девелопер).
Я им говорю, что RSA НЕ предназначен для шифрования больших объемов данных. Просто физически это невозможно, для этого есть тот же AES например. У асимметричных и симметричных алгоритмов разные цели абсолютно и не надо пытаться применить один алгоритм, если у него другая цель. Мне в ответ "ну вот мы пообещали RSA и барклай согласился и надо делать RSA"Так может прежде, чем предлагать что то, надо сначала понять а подойдет ли это решение? Разумно ли его пользовать? я уже устал присылать им статьи в инете..
может кто подскажет ссылку на статью, которая ясно и четко покажет для чего нужен RSA и для чего AES...
ну можно создать внешний домен для кастомеров - и используя directory services законнектить все к базе (Oracle EUS for example). но в принципе и хранение app users в базе это не криминал - просто хеш вместо plain text password - это как бы закон!