Спасибо за статью. Выглядит так, что и для AI решений нужно писать автоматизированные тесты. Ведь для любой предметной области можно найти контрольные примеры, где для известных входных данных точно известен результат.
Атака шифровальщика обойдется нам в 30 миллионов рублей прямого убытка от простоя. Чтобы снизить этот риск на 95%, нам нужно инвестировать 2 миллиона в современное решение для защиты конечных точек.
Поделитесь пожалуйста методикой подсчета подобных цифр, откуда инженеру взять вводные для такого расчета?
Грамотная реализация шифрования или хэширования должна быть non-deterministic, то выглядеть как псевдослучайная информация. Соль должна быть уникальной для каждой записи в такой БД. Хэшированные данные станут подобны белому шуму.
Однако такая реализация не позволит построить поисковый индекс, чтобы находить записи по исходным данным, потому что результат хэширования без знания соли случаен.
Неизбежно придется идти на компромиссы, реализуя все-таки deterministic хэширование. Однако и его можно реализовать так, что вычислительные затраты на подбор хэша окажутся неприемлемыми.
Я бы предложил реализовать задачу хэширования следующим образом:
1. Нормализовать номер паспорта в строку, как исходные данные
2. Создать скажем 10 (100, etc) статических солей размерностью в 128 бит, сохранить их БД в соседней таблице
3. Рассчитать хэш-функцию blake2b от исходных данных, взять остаток от деления на 10 (100, etc), это будет порядковый номер соли
4. Рассчитать хэш-функцию Argon2 с параметрами: выбранная соль, исходные данные, размер получаемого digest 256 bit, parallelism=1, memory=16..32 MiB, iterations=5..7.
Хэш-функции семейства Argon2 спроектированы для противодействия атакам перебора на фермах GPU, они обеспечивают не только вычислительную нагрузку, но и расход памяти, также невозможность распарралелливания вычислений. Перебор хэшей Argon2 займет неприемлемое время. Вычисление одного хэша для поиска по БД займет почти незаметное для пользователя время.
Молодцы! Почта все-таки меняется, а это крайне непростое дело в масштабах такой организации. Вот бы вам только не превращать почту в супермаркет ничего конкретного, а развивать бы основной бизнес — службы доставки, экспресс-доставку товаров и документов, грузов.
Автор верно отмечает разницу между оценкой трудозатрат и планом реализации.
Проблемы начинаются тогда, когда оценка трудозатрат автоматически становится дедлайном.
Оценки и планирование нужны хотя бы для того чтобы получить необходимые ресурсы для проекта.
Статья отличная, но поясните пожалуйста как вы измеряете и управляете компетенциями в области бизнес-домена (не техническими)? Эффективному разработчику важно знать и понимать бизнес-контекст задачи, а не только технические инструменты.
У каждого сервиса свои нюансы. Контроллеры и DTO у нас есть. Кроме формата сообщений есть и поведение сервиса, эта часть автогенерацией кода пока не решается. Задача полностью автоматической валидации формата и поведения у нас пока не решена, но я думаю, при наличии положительны результатов, это будет материал для отдельной статьи.
Отличная статья. Реализовать на одной диаграмме всю совокупность слоев архитектуры выглядит как утопия — сложность задачи будет неприемлема. Расскажите как вы декомпозируете описание архитектуры на набор View в ArchiMate?
GraphQL безусловно отличный продукт, но имеет свою, ограниченную область применения. Специфический протокол graphql пока поддерживается не всеми языками и платформами, а для публичного API крайне важно дать инструмент абсолютно совместимый со всеми платформами и языками. Интеграция с HTTP+JSON на сегодняшний день абсолютно универсальна.
Пробовали некоторые подходы, но в итоге у нас это не прижилось в большинстве проектов. Автоматический генератор кода создает лишь структуры данных, но не поведение. Реализация правильного поведения есть основная часть работы. Конечно, для бинарных протоколов наподобие gRPC или GraphQL, генератор кода из схемы абсолютно необходим.
Абсолютно верно. Следует разделять слои транспорта и бизнес-логики. REST это про декомпозицию сущностей и операций над ними в набор ресурсов, а не про HTTP-глаголы и наборы http status кодов.
On Nov. 5, 2015, SmartBear in conjunction with 3Scale, Apigee, Capital One, Google, IBM, Intuit, Microsoft, PayPal, and Restlet announced the formation of the Open API Initiative, an open source project under the Linux Foundation. As part of the formation of the OAI, SmartBear donated the Swagger specification to the Linux Foundation, meaning that the OpenAPI Specification is semantically identical to the specification formerly known as the Swagger 2.0 specification.
Спасибо за статью.
Выглядит так, что и для AI решений нужно писать автоматизированные тесты.
Ведь для любой предметной области можно найти контрольные примеры, где для известных входных данных точно известен результат.
С утверждениями не спорим, но тема до конца не раскрыта — а как сделать так, чтобы нейросетевые функции были строго детерминированы?
PCI-DSS v.4.0.1 предписывает так же реализовать механизм регулярной и внеплановой ротации ключей, как шифрования, так и хэширования.
А еще есть хэш-функции с солью и перцем, например BLAKE2 - так можно сделать многофакторный секрет.
Благодарю)
Поделитесь пожалуйста методикой подсчета подобных цифр, откуда инженеру взять вводные для такого расчета?
Однако такая реализация не позволит построить поисковый индекс, чтобы находить записи по исходным данным, потому что результат хэширования без знания соли случаен.
Неизбежно придется идти на компромиссы, реализуя все-таки deterministic хэширование. Однако и его можно реализовать так, что вычислительные затраты на подбор хэша окажутся неприемлемыми.
Я бы предложил реализовать задачу хэширования следующим образом:
1. Нормализовать номер паспорта в строку, как исходные данные
2. Создать скажем 10 (100, etc) статических солей размерностью в 128 бит, сохранить их БД в соседней таблице
3. Рассчитать хэш-функцию blake2b от исходных данных, взять остаток от деления на 10 (100, etc), это будет порядковый номер соли
4. Рассчитать хэш-функцию Argon2 с параметрами: выбранная соль, исходные данные, размер получаемого digest 256 bit, parallelism=1, memory=16..32 MiB, iterations=5..7.
Хэш-функции семейства Argon2 спроектированы для противодействия атакам перебора на фермах GPU, они обеспечивают не только вычислительную нагрузку, но и расход памяти, также невозможность распарралелливания вычислений. Перебор хэшей Argon2 займет неприемлемое время. Вычисление одного хэша для поиска по БД займет почти незаметное для пользователя время.
Проблемы начинаются тогда, когда оценка трудозатрат автоматически становится дедлайном.
Оценки и планирование нужны хотя бы для того чтобы получить необходимые ресурсы для проекта.
Буду благодарен за информацию по методике анализа взаимного влияния проектов в общей информационной системе.
github.com/lord/slate
www.npmjs.com/package/widdershins
github.com/Rebilly/ReDoc
Swagger-UI, по моему мнению пригоден лишь как внутренний инструмент.