Шифрование в dax2012

[Владимир Максимов]

С регистрацией на сайте беда. Админов поймать невозможно, чтобы ускорить процесс. Поэтому работаю "почтальоном"

-------------------------------

Немного поясню:

• Кластер DAX2012 (несколько десятков АОС).
• Пакетное задание DAX (любой из этих АОС теоретически может быть назначен пакетным сервером) при выполнении обращается к неким внешним ресурсам, используя при этом логин и пароль.
• Этих ресурсов несколько десятков.

То есть аксапта должна уметь расшифровать хранящийся пароль и передать его внешнему ресурсу при авторизации. Так как АОСов много, использовать стандартное шифрование мы не можем, так как ключ шифрования хранится в реестре сервера и нам нужно будет хранить для каждого АОСа свой экземпляр зашифрованного пароля.

Так вот в чем собственно вопрос:

• каким образом организовывать шифрование-дешифрование
• каким образом организовывать хранение и доступ к ключам шифрования
• если кто то ткнет меня в ресурсы или в код будет вообще шикарно

Цитата:

Сообщение от Товарищ ♂uatr

Вы рассматривали вариант с использованием сертификатов и открытых/закрытых ключей?

Мы рассматриваем любую приемлемую схему

Цитата:

Сообщение от axm2017

Вопрос где мы собираемся хранить/держать пароли (будет ли их пользователь вводить или как то иначе)?

Атрибуты подключения будут заводится руками пользователем при регистрации связи с ресурсом.

Цитата:

Сообщение от axm2017

Депонирование ключей нужно ли при этом?

Тут я не могу придумать сценарий когда это понадобится.

[axm2017]

Хранить данные для доступа в зашифрованном симметричным алгоритмом виде в табличке.
При работе пакета сессия при запуске обращается к сетевому ресурсу (файл в сети с паролем расшифровки), доступ к которому есть только у пользователей группы пакетные задания/АОСы.

[Товарищ ♂uatr]

Цитата:

Сообщение от Владимир Максимов

Есть массив паролей (несколько десятков тысяч) они лежат в таблице Dax2012. Их нужно зашифровать.

Цитата:

Сообщение от Владимир Максимов

[*]каким образом организовывать хранение и доступ к ключам шифрования

Ощущение, что Вы "уперлись" в проблему созданную каким-то одним из множества вариантов решения бизнес-задачи (см. DDD). Как звучит бизнес задача?
Здесь Kerebros так и просится в качестве хранилища аутентификационных данных и инструмента для валидации.

[gl00mie]

Цитата:

Сообщение от Владимир Максимов

• Кластер DAX2012 (несколько десятков АОС).
• Пакетное задание DAX (любой из этих АОС теоретически может быть назначен пакетным сервером) при выполнении обращается к неким внешним ресурсам, используя при этом логин и пароль.
• Этих ресурсов несколько десятков.

То есть аксапта должна уметь расшифровать хранящийся пароль и передать его внешнему ресурсу при авторизации.
Так вот в чем собственно вопрос:

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

Обычный подход в таких случаях следующий:

• на любом хосте генерится экспортируемый (!) самоподписанный сертификат с использованием асимметричного алгоритма шифрования, такого как RSA или Diffie–Hellman (например, RSA2048), лучше всего со сроком действия лет на 100. В справке по развертыванию D365FO есть рекомендации по настройкам генерации сертификатов. Сгенерить сертификат можно с помощью PowerShell, см. New-SelfSignedCertificate
• сам сертификат на хосте, где он сгенерирован, экспортируется с закрытым ключом в pfx-файл (скажем, с помощью MMC-оснастки Certificates), при этом закрытый ключ защищается паролем.
• экспортированный сертификат с закрытым ключом на всех хостах, где им нужно будет что-то расшифровывать, импортируется в cert:\LocalMachine\My в терминах PowerShell (он же Computer\Personal в MMC-оснастке Certificates)
• на закрытый ключ с помощью MMC-оснастки Certificates или с помощью PowerShell дается доступ на чтение той учетке или доменной группе, под которой запускаются сервисы AOS-ов. По умолчанию доступ будет только у LocalSystem, локального администратора и того, кто импортировал сертификат.
• на открытом ключе сертификата зашифровываются приватные данные и сохраняются в базе или еще где, да хоть на сетевой шаре.
• в коде, где нужно прочитать приватные данные, тому же RSACryptoServiceProvider говорится "расшифруй массив байт". Класс сам из зашифрованных данных извлекает отпечаток сертификата, сам запрашивает его закрытый ключ на хосте и расшифровывает данные (если что не так - будет исключение)
• после использования расшифрованных данных не забыть выжечь их в оперативной памяти каленым железом, чтобы кто-нить дамп не снял
• profit!

[Владимир Максимов]

Цитата:

Сообщение от gl00mie

самоподписанный сертификат с использованием асимметричного алгоритма шифрования

Поправьте меня если я не прав, но на АОС для доступа к контейнеру с закрытым ключом нужен ПИН. А если так, то опять встает вопрос - как этот ПИН безопасно хранить?

[gl00mie]

Цитата:

Сообщение от Владимир Максимов

Поправьте меня если я не прав, но на АОС для доступа к контейнеру с закрытым ключом нужен ПИН

Требовать каждый раз ПИН или еще что - это одна из опций защиты закрытого ключа, которая имеет смысл, скажем, для клиент-банка. В общем же случае никаких ПИНов не требуется, доступ определяется обычными ACL, как и к файлам на диске. По описанным выше принципам настроено использование сертификатов в D365FO и не только: импортируете с закрытым ключом в cert:\LocalMachine\My, раздаете права доступа на закрытый ключ учеткам или их группам - и готово. Посмотрите, как работают те же SSL-сертификаты. Дали доступ к закрытому ключу, указали отпечаток сертификата в настройках (чтобы приложение знало, какой сертификат грузить) - и готово, никто ж не вводит никакие ПИНы при перезапуске веб-серверов, или того же SQL Server, или любой другой службы, которая умеет использовать SSL-сертификаты.

[Lemming]

Ребят, я за рулем, на всякий случай ещё этот вариант рассмотрите https://ru.wikipedia.org/wiki/MTProto

[Lemming]

Позже будут подробности