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

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

Вопрос не мой, транслирую "как сформировали" (без понимания смысла). Поэтому на уточняющие вопросы могу отвечать с задержкой


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

Использование стандарта ограничено тем что использование WinAPIServer::cryptProtectData()и WinAPServer::cryptUnprotectData() подразумевает что ключ лежит в реестре на сервере АОС а серверов более 80. То есть необходимо хранить 80 экземпляров зашифрованного пароля для каждого АОС.

Вопрос:

1. какие могут быть варианты хранения ключей.
2. какие могут быть вообще варианты организации шифрования

[axm2017]

Шифровать для чего?
Правильно хранить пароль в виде результата хэш функции.
Пользователь вводит пароль к нему применяют хэш функцию и сравнивают с хранимым. В таком случае даже при попадании базы в чужие руки все ок.

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

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

Мне нужно шифровать - дешифровать. То есть восстанавливать из того что хранится, то что сохраняли.

Возможно постановка "хранятся пароли" немного некорректный. Скорее так "хранится некая конфиденциальная информация"

[axm2017]

Ок пусть храниться некая информация.
Мы ее шифруем/расшифровываем с помощью какого то алгоритма А
Вопрос где мы собираемся хранить/держать пароли (будет ли их пользователь вводить или как то иначе)?
Депонирование ключей нужно ли при этом?

[Товарищ ♂uatr]

Добрый день.
Кто та сторона, что должна обладать расшифрованным паролем?
Вы рассматривали вариант с использованием сертификатов и открытых/закрытых ключей?

[imir]

Если есть пара открытый-закрытый ключ, то можно попользоваться System.Security.Cryptography; наверное
Пример на C# нарыт в интернетах.

Вопрос - где надежно хранить закрытый ключ для дешифрования, в ресурс зашивать или в папке, в кторую имеет доступ только учетка AOS - ну такие себе варианты.

using System;
using System.Security.Cryptography;
using System.Text;

namespace RSAEncryptionExample
{
    class Program
    {
        static void Main(string[] args)
        {
            string originalText = "Text to be encrypted";
            byte[] encryptedText;

            // Get the public key from a file
            string publicKey = File.ReadAllText("publickey.xml");

            // Create an instance of the RSA algorithm with the public key
            RSA rsa = RSA.Create();
            rsa.FromXmlString(publicKey);

            // Encrypt the original text using the RSA algorithm
            encryptedText = rsa.Encrypt(Encoding.UTF8.GetBytes(originalText), RSAEncryptionPadding.OaepSHA1);

            Console.WriteLine("Encrypted Text: " + Convert.ToBase64String(encryptedText));
        }
    }
}

[axm2017]

Хранить можно как глобальную переменную в рамках сессии. Пользователь ввел пароль и далее живёт пока жива сессия.

[Raven Melancholic]

Цитата:

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

Хранить можно как глобальную переменную в рамках сессии. Пользователь ввел пароль и далее живёт пока жива сессия.

Да, но опять же возникает вопрос, а зачем обычному пользователю знать пароль, например для доступа к Emarsys, с которым происходит обмен?
Даже если самим обменом занимается пакетная задача, то где тогда хранить этот пароль между запусками пакета?

[axm2017]

Ему и не надо: ему надо ввести пароль чтобы получить доступ к табличке в которой зашифрованы данные для доступа к emarsys

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

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

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

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

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

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

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

[dim-gin]

Из самого очевидного: с помощью упомянутого System.Security.Cryptography шифровать по ключу, который суть какой-то параметр БД или ОС под БД (название или вообще отдельное свойство в реестре спрятать). Кроме АОСов и админов, по-хорошему, никто не должен обладать правами чтения такой информации.

[axm2017]

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

[Raven Melancholic]

Или вообще замахнуться на WEB службу управления такими паролями.
То есть, установка и чтение только через WEB службу, а она пусть использует тот же System.Security.Cryptography добившись, что работать будет на одном сервере.

Но тут беда - сломался этот уникальный сервер и остались без паролей.

[raz]

Если в DAX2012 есть таблицы CreditCard*, то там можно найти простой вариант шифрования.

[Товарищ ♂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]

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