Visitors have accessed this post 15565 times.
Visitors have accessed this post 15565 times.
Перевод статьи — https://opensource.com/article/19/6/cryptography-basics-openssl-part-2
Детальный обзор шифрования в OpenSSL: хеши, цифровые подписи, цифровые сертификаты и многое другое
В первой статье из этой серии мы познакомились с хешами, шифрованием/дешифрованием, цифровыми подписями и сертификатами в библиотеках OpenSSL, утилитами командной строки. Во второй статье будет подробное изложение этого материала. Давайте начнем с хешей, которые широко используются в вычислениях, и рассмотрим, как создать криптографическую хеш-функцию.
Страница загрузки исходного кода OpenSSL (https://www.openssl.org/source/) содержит таблицу с последними версиями. Каждая версия имеет два значения хеш-функции: 160-bit SHA1 и 256-bit SHA256. Эти значения можно использовать для проверки соответствия загруженного файла оригиналу в репозитории: загрузчик пересчитывает значения хеш-функции локально в загруженном файле, а затем сравнивает результаты с оригиналами. Современные системы уже имеют встроенные утилиты для вычисления подобных хешей. Операционная система Linux, например, имеет хеши md5sum и sha256sum. В OpenSSL предусмотрены аналогичные утилиты командной строки.
Хеши используются во многих областях вычислений. Например, блокчейн биткойнов использует хеш-значения SHA256 в качестве идентификаторов блоков. Чтобы майнить биткойн, необходимо сгенерировать хеш-значение SHA256, которое падает ниже заданного порога, то есть, хеш-значение как минимум с начальными нулями N. (Значение N может увеличиваться или уменьшаться в зависимости от того, насколько продуктивен майнинг в конкретное время). Интересно, что современные майнеры представляют собой аппаратные кластеры, предназначенные для параллельной генерации хешей SHA256. Во время пикового периода в 2018 году майнеры биткойнов по всему миру генерировали около 75 миллионов терахешей в секунду — еще одно непостижимое число.
Сетевые протоколы также используют хеш-значения — часто под именем контрольной суммы — для поддержки целостности сообщения; то есть, чтобы убедиться, что полученное сообщение совпадает с отправленным. Отправитель сообщения вычисляет контрольную сумму сообщения и отправляет результаты вместе с сообщением. Получатель пересчитывает контрольную сумму при получении сообщения. Если отправленная и пересчитанная контрольная сумма не совпадают, то что-то случилось с сообщением при передаче, либо с отправленной контрольной суммой, либо с обеими. В этом случае сообщение и его контрольную сумму следует отправить повторно или, по крайней мере, создать условие ошибки. (Сетевые протоколы низкого уровня, такие как UDP, не запариваются насчет контрольных сумм).
Другие примеры хешей более или менее известны. Рассмотрим веб-сайт, требующий от пользователей аутентификации с паролем, который пользователь вводит в своем браузере. Пароль затем отправляется в зашифрованном виде из браузера на сервер через HTTPS-соединение с сервером. Когда пароль поступает на сервер, он дешифруется для поиска в базе данных по таблице.
Что должно храниться в этой таблице поиска? Хранить одни пароли — рискованное дело. Гораздо менее рискованно хранить хеш, сгенерированный из пароля, возможно, с добавлением некоторой соли (дополнительных битов) по вкусу до вычисления значения хеша. Ваш пароль может быть отправлен на веб-сервер, но сайт может заверить вас, что на самом деле пароль там не хранится.
Хеш-значения также встречаются в различных сферах безопасности. Например, код аутентификации сообщений на основе хеша (HMAC) использует значение хеш-функции и секретный криптографический ключ для аутентификации сообщения, отправленного по сети. Коды HMAC, которые так легки и просты в использовании в программах, популярны и в веб-сервисах. Цифровой сертификат X509 включает в себя значение хеш-функции, известное как отпечаток пальца, что может облегчить проверку сертификата. Хранилище доверенных сертификатов в памяти может быть реализовано в виде таблицы поиска, основанной на таких отпечатках, как хеш-карты с постоянным временем выборки. Отпечаток от входящего сертификата можно сравнить с ключами хранилища доверенных сертификатов на совпадение.
Какой особенностью должна обладать криптографическая хеш-функция? Она должна быть односторонней, то есть, очень трудно инвертированной. Криптографическая хеш-функция должна быть относительно простой для вычисления, но вычисление ее обратной функции — функции, которая отображает значение хеш-функции во входную строку битов — должно быть неразрешимым с точки зрения вычислений. Вот иллюстрация с chf в качестве криптографической хеш-функции и паролем foobar в качестве примера ввода:
+---+ foobar—>|chf|—>хеш-значение ## прямолинейное +--–+
Для сравнения, обратная операция является невозможной:
+-----------+ хеш-значение—>|chf inverse|—>foobar ## труднорешаемое +-----------+
Вспомните, например, хеш-функцию SHA256. Для входной строки битов любой длины N> 0 эта функция генерирует хеш-значение фиксированной длины, равное 256 битам; следовательно, это значение хеша не показывает даже длину N входной строки битов, не говоря уже о значении каждого бита в строке. Кстати, SHA256 не подвержен атаке удлинением сообщения. Единственный эффективный способ обратного инжиниринга вычисленного значения хеш-функции SHA256 обратно во входную строку битов — это поиск методом последовательного перебора, то есть, перебор каждой возможной входной строки битов, пока не будет найдено совпадение с целевым значением хеш-функции. Такой поиск невозможен с использованием криптографической хеш-функции SHA256.
Теперь финальная точка обзора в порядке. Криптографические хеш-значения статистически, но не безусловно уникальны, а это означает, что две разные входные строки битов вряд ли, но возможно, выдают одно и то же хеш-значение — коллизию. Парадокс дней рождения представляет собой довольно противоречивый пример коллизий. Существует обширное исследование устойчивости к коллизиям различных хеш-алгоритмов. Например, MD5 (128-битные значения хеша) имеет разбивку в сопротивлении коллизии после примерно 221 хеша. Для SHA1 (160-битные значения хеша) разбивка начинается примерно с 261 хеша.
Пока что нет точной оценки пробоя в сопротивлении коллизии для SHA256. И это не удивительно. SHA256 имеет диапазон 2256 различных значений хеша, число, десятичное представление которого имеет 78 цифр! Бывают ли коллизии с хешированием SHA256? Конечно, но они крайне маловероятны.
В следующих примерах командной строки в качестве источников строк битов используются два входных файла: hashIn1.txt и hashIn2.txt. Первый файл содержит значения abc, а второй — 1a2b3c.
Для удобства чтения файл содержит текст, но вместо этого можно использовать двоичные файлы.
Используя утилиту Linux sha256sum для этих двух файлов в командной строке — со знаком процента (%) в качестве приглашения, можно создать следующие значения хеша (в шестнадцатеричной форме):
% sha256sum hashIn1.txt 9e83e05bbf9b5db17ac0deec3b7ce6cba983f6dc50531c7a919f28d5fb3696c3 hashIn1.txt % sha256sum hashIn2.txt 3eaac518777682bf4e8840dd012c0b104c2e16009083877675f00e995906ed13 hashIn2.txt
Как и ожидалось, хешированные аналоги OpenSSL дают те же результаты:
% openssl dgst -sha256 hashIn1.txt SHA256(hashIn1.txt)= 9e83e05bbf9b5db17ac0deec3b7ce6cba983f6dc50531c7a919f28d5fb3696c3 % openssl dgst -sha256 hashIn2.txt SHA256(hashIn2.txt)= 3eaac518777682bf4e8840dd012c0b104c2e16009083877675f00e995906ed13
Этот анализ криптографических хеш-функций позволяет более подробно рассмотреть цифровые подписи и их связь с парами ключей.
Как следует из названия, цифровая подпись может быть прикреплена к документу или другому электронному артефакту (например, программе), чтобы подтвердить его подлинность. Такая подпись аналогична рукописной подписи на бумажном документе. Для проверки цифровой подписи нужно подтвердить две вещи. Во-первых, что проверенный артефакт не изменился с тех пор, как подпись была прикреплена, потому что он частично основан на криптографическом хеше документа. Во-вторых, что подпись принадлежит человеку (например, Алисе), единственному, кто имеет доступ к закрытому ключу в паре. Кстати, цифровая подпись кода (исходного или скомпилированного) — уже обычная практика среди программистов.
Давайте поэтапно разберем, как создается цифровая подпись. Как упоминалось ранее, цифровая подпись должна иметь пары открытого и закрытого ключей. При использовании OpenSSL для создания этих ключей существует две отдельные команды: одна для создания закрытого ключа, а другая для извлечения соответствующего открытого ключа из закрытого. Эти пары ключей кодируются в base64, и их размеры могут быть указаны во время этого процесса.
Закрытый ключ состоит из числовых значений, два из которых (модуль и показатель степени) составляют открытый ключ. Хотя файл закрытого ключа содержит открытый ключ, извлеченный открытый ключ не отображает значение соответствующего закрытого ключа.
Таким образом, полученный файл с закрытым ключом содержит полную пару ключей. Извлечение открытого ключа в его собственный файл является практичным, потому что оба ключа имеют различное использование, но это извлечение также сводит к минимуму риск того, что закрытый ключ может случайно появится в открытом доступе.
Затем закрытый ключ пары используется для обработки хеш-значения для целевого артефакта (например, электронной почты), создавая тем самым подпись. С другой стороны, система получателя использует открытый ключ пары для проверки подписи, прикрепленной к артефакту.
Теперь рассмотрим на примере. Для начала сгенерируем 2048-битную пару ключей RSA с OpenSSL:
openssl genpkey -out privkey.pem -algorithm rsa 2048
В этом примере мы можем убрать флаг -algorithm rsa, поскольку по умолчанию genpkey имеет тип RSA. Имя файла (privkey.pem) является произвольным, но расширение pem Privacy Enhanced Mail (PEM) является стандартным для формата PEM по умолчанию. (Если необходимо, в OpenSSL есть команды для преобразования между форматами.) Если требуется больший размер ключа (например, 4096), то последний аргумент 2048 можно изменить на 4096. Эти размеры всегда имеют степень двойки.
Вот фрагмент получившегося файла privkey.pem, который находится в base64:
-----BEGIN PRIVATE KEY----- MIICdgIBADANBgkqhkiG9w0BAQEFAASCAmAwggJcAgEAAoGBANnlAh4jSKgcNj/Z JF4J4WdhkljP2R+TXVGuKVRtPkGAiLWE4BDbgsyKVLfs2EdjKL1U+/qtfhYsqhkK … -----END PRIVATE KEY-----
Следующая команда затем извлекает открытый ключ пары из закрытого:
openssl rsa -in privkey.pem -outform PEM -pubout -out pubkey.pem
Полученный файл pubkey.pem небольшой, поэтому его можно отобразить в полном виде:
-----BEGIN PUBLIC KEY----- MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDZ5QIeI0ioHDY/2SReCeFnYZJY z9kfk11RrilUbT5BgIi1hOAQ24LMilS37NhHYyi9VPv6rX4WLKoZCmkeYaWk/TR5 4nbH1E/AkniwRoXpeh5VncwWMuMsL5qPWGY8fuuTE27GhwqBiKQGBOmU+MYlZonO O0xnAKpAvysMy7G7qQIDAQAB -----END PUBLIC KEY-----
Теперь, имея под рукой пару ключей, цифровую подпись создать очень просто. В данном случае, исходный файл client.c выступает в качестве артефакта, который необходимо подписать:
openssl dgst -sha256 -sign privkey.pem -out sign.sha256 client.c
Дайджестом для исходного файла client.c является хеш-функция SHA256, а закрытый ключ находится в ранее созданном файле privkey.pem. Полученный файл двоичной подписи — это sign.sha256, то есть, произвольное имя. Чтобы получить читабельную (с помощью base64) версию этого файла, выполните следующую команду:
openssl enc -base64 -in sign.sha256 -out sign.sha256.base64
Файл sign.sha256.base64 теперь содержит:
h+e+3UPx++KKSlWKIk34fQ1g91XKHOGFRmjc0ZHPEyyjP6/lJ05SfjpAJxAPm075 VNfFwysvqRGmL0jkp/TTdwnDTwt756Ej4X3OwAVeYM7i5DCcjVsQf5+h7JycHKlM o/Jd3kUIWUkZ8+Lk0ZwzNzhKJu6LM5KWtL+MhJ2DpVc=
Или же, вместо этого, можно подписать исполняемый файл-клиент, но при этом, полученная подпись в кодировке base64 естественно будет отличаться:
VMVImPgVLKHxVBapJ8DgLNJUKb98GbXgehRPD8o0ImADhLqlEKVy0HKRm/51m9IX xRAN7DoL4Q3uuVmWWi749Vampong/uT5qjgVNTnRt9jON112fzchgEoMb8CHNsCT XIMdyaPtnJZdLALw6rwMM55MoLamSc6M/MV1OrJnk/g=
Заключительный этап в этом процессе — это проверка цифровой подписи с открытым ключом. Хеш, используемый для подписи артефакта (в данном случае исполняемой программой-клиентом), должен быть пересчитан как важный этап проверки, поскольку процесс проверки должен указывать, изменился ли артефакт с момента подписания.
Для этого используются две команды OpenSSL. Первый расшифровывает подпись base64:
openssl enc -base64 -d -in sign.sha256.base64 -out sign.sha256
Второй проверяет подпись:
openssl dgst -sha256 -verify pubkey.pem -signature sign.sha256 client
Вывод второй команды должен показать результат:
Verified OK
Чтобы понять, что происходит при сбое проверки, существует краткое, но полезное упражнение, суть которого заменить исполняемый файл клиента в последней команде OpenSSL исходным файлом client.c, а затем выполнить проверку. Другое упражнение состоит в том, чтобы немного изменить программу-клиент и повторить попытку.
Цифровой сертификат объединяет фрагменты, проанализированные до настоящего момента: хеш-значения, пары ключей, цифровые подписи и шифрование/дешифрование. Первым этапом на пути к получению сертификата производственного уровня является создание запроса на подпись сертификата (CSR), который затем отправляется в центр сертификации (CA). Чтобы сделать это с помощью OpenSSL, запустите:
openssl req -out myserver.csr -new -newkey rsa:4096 -nodes -keyout myserverkey.pem
В этом примере создается документ CSR и сохраняется документ в файле myserver.csr (текст base64). Для чего это нужно: документ CSR отправляет запрос, чтобы ценрт сертификации поручился за его идентичность с указанным доменным именем — общим именем (CN) в CA.
Новая пара ключей также генерируется этой командой, хотя можно использовать уже существующую пару. Обратите внимание, что использование сервера в именах myserver.csr и myserverkey.pem, указывает на типичное использование цифровых сертификатов: в качестве поручителей идентификации веб-сервера, связанного с доменом как, например, www.google.com.
Однако эта же команда создает CSR независимо от способа использования цифрового сертификата. Она точно также запускает интерактивный сеанс вопросов/ответов, который запрашивает соответствующую информацию о доменном имени для связи с цифровым сертификатом запрашивающей стороны. Этот интерактивный сеанс может прерваться путем предоставления основ в рамках команды с обратными слешами в качестве продолжения через разрывы строк. Флаг -subj вводит необходимую информацию:
% openssl req -new -newkey rsa:2048 -nodes -keyout privkeyDC.pem -out myserver.csr -subj "/C=US/ST=Illinois/L=Chicago/O=Faulty Consulting/OU=IT/CN=myserver.com"
Полученный документ CSR может быть проверен перед отправкой в CA. Этот процесс создает цифровой сертификат с желаемым форматом (например, X509), подписью, датами действия и т. д.
openssl req -text -in myserver.csr -noout -verify
Вот фрагмент вывода:
verify OK Certificate Request: Data: Version: 0 (0x0) Subject: C=US, ST=Illinois, L=Chicago, O=Faulty Consulting, OU=IT, CN=myserver.com Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: 00:ba:36:fb:57:17:65:bc:40:30:96:1b:6e:de:73: … Exponent: 65537 (0x10001) Attributes: a0:00 Signature Algorithm: sha256WithRSAEncryption …
При разработке веб-сайта с HTTPS протоколом желательно иметь цифровой сертификат под рукой, не проходя процесс сертификации. Самостоятельно сгенерированный сертификат заполняет счет на этапе аутентификации HTTPS, хотя любой современный браузер предупреждает, что такой сертификат не нужен. Продолжая пример, ниже приводится команда OpenSSL для самостоятельно сгенерированного сертификата, действительного в течение года и с открытым ключом RSA:
openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:4096 -keyout myserver.pem -out myserver.crt
Ниже приводится читабельная версия сгенерированного сертификата через команду OpenSSL:
openssl x509 -in myserver.crt -text -noout
Вот фрагмент вывода самостоятельно сгенерированного сертификата:
Certificate: Data: Version: 3 (0x2) Serial Number: 13951598013130016090 (0xc19e087965a9055a) Signature Algorithm: sha256WithRSAEncryption Issuer: C=US, ST=Illinois, L=Chicago, O=Faulty Consulting, OU=IT, CN=myserver.com Validity Not Before: Apr 11 17:22:18 2019 GMT Not After : Apr 10 17:22:18 2020 GMT Subject: C=US, ST=Illinois, L=Chicago, O=Faulty Consulting, OU=IT, CN=myserver.com Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (4096 bit) Modulus: 00:ba:36:fb:57:17:65:bc:40:30:96:1b:6e:de:73: … Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Subject Key Identifier: 3A:32:EF:3D:EB:DF:65:E5:A8:96:D7:D7:16:2C:1B:29:AF:46:C4:91 X509v3 Authority Key Identifier: keyid:3A:32:EF:3D:EB:DF:65:E5:A8:96:D7:D7:16:2C:1B:29:AF:46:C4:91 X509v3 Basic Constraints: CA:TRUE Signature Algorithm: sha256WithRSAEncryption 3a:eb:8d:09:53:3b:5c:2e:48:ed:14:ce:f9:20:01:4e:90:c9: …
Как упоминалось ранее, закрытый ключ RSA содержит значения, по которым генерируется открытый ключ. Однако, открытый ключ не выдает соответствующий закрытый ключ.
Существует важное соответствие между цифровым сертификатом и парой ключей, используемой для создания сертификата, даже если сертификат самостоятельно сгенерирован:
Модуль — это большое значение, которое может быть хешировано для удобства прочтения. Ниже приведены две команды OpenSSL, которые проверяют один и тот же модуль, тем самым подтверждая, что цифровой сертификат основан на паре ключей в файле PEM:
Certificate: Data: Version: 3 (0x2) Serial Number: 13951598013130016090 (0xc19e087965a9055a) Signature Algorithm: sha256WithRSAEncryption Issuer: C=US, ST=Illinois, L=Chicago, O=Faulty Consulting, OU=IT, CN=myserver.com Validity Not Before: Apr 11 17:22:18 2019 GMT Not After : Apr 10 17:22:18 2020 GMT Subject: C=US, ST=Illinois, L=Chicago, O=Faulty Consulting, OU=IT, CN=myserver.com Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (4096 bit) Modulus: 00:ba:36:fb:57:17:65:bc:40:30:96:1b:6e:de:73: … Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Subject Key Identifier: 3A:32:EF:3D:EB:DF:65:E5:A8:96:D7:D7:16:2C:1B:29:AF:46:C4:91 X509v3 Authority Key Identifier: keyid:3A:32:EF:3D:EB:DF:65:E5:A8:96:D7:D7:16:2C:1B:29:AF:46:C4:91 X509v3 Basic Constraints: CA:TRUE Signature Algorithm: sha256WithRSAEncryption 3a:eb:8d:09:53:3b:5c:2e:48:ed:14:ce:f9:20:01:4e:90:c9: …
Полученные значения хеш-функции совпадают, подтверждая тем самым, что цифровой сертификат основан на указанной паре ключей.
Давайте вернемся к вопросу, затронутому в конце 1 статьи: согласование TLS между программой-клиентом и веб-сервером Google. Существуют различные протоколы согласования, и даже версия протокола Диффи-Хеллмана в работе на примере клиента предлагает возможность для различных манипуляций. Тем не менее, пример клиента следует общему шаблону.Для начала во время согласования TLS, программа-клиент и веб-сервер согласовывают набор шифров, который состоит из используемых алгоритмов. В данном случае, набор включает: ECDHE-RSA-AES128-GCM-SHA256.Сейчас нас интересуют два элемента: алгоритм пары ключей RSA и блочный шифр AES128, используемый для шифрования и дешифрования сообщений в случае успешного установления связи. Что касается шифрования/дешифрования, этот процесс имеет два варианта: симметричный и асимметричный. В симметричном варианте один и тот же ключ используется для шифрования и дешифрования, что в первую очередь поднимает вопрос распространения ключей: как безопасно распространять ключ для обеих сторон? В асимметричном варианте один ключ используется для шифрования (в данном случае открытый ключ RSA), а другой ключ используется для расшифровывания (в данном случае закрытый ключ RSA из той же пары).Программа-клиент имеет открытый ключ веб-сервера Google из сертификата аутентификации, а веб-сервер имеет закрытый ключ из той же пары. Соответственно, программа-клиент может отправлять зашифрованное сообщение на веб-сервер, который сам по себе может легко расшифровать это сообщение.В ситуации с протоколом TLS, симметричный подход имеет два существенных преимущества:
Согласование TLS разумно сочетает в себе два вида шифрования/дешифрования. Во время согласования, программа-клиент генерирует случайные биты, называемые секретом (pre-master secret (PMS)). Затем программа-клиент шифрует PMS с помощью открытого ключа сервера и отправляет зашифрованный PMS на сервер, который, в свою очередь, дешифрует сообщение PMS своим закрытым ключом из пары RSA:
+-------------------+ зашифрованныйPMS +--------------------+ клиент PMS--->|открытый ключ сервера|--------------->|закрытый ключ сервера|---> сервер PMS +-------------------+ +--------------------+
В конце этого процесса, программа-клиент и веб-сервер Google теперь имеют одинаковые биты PMS. Каждая сторона использует эти биты для генерации секрета, а затем и симметричного ключа шифрования/дешифрования, известного как сеансовый ключ. Теперь есть два разных, но идентичных сеансовых ключа, по одному на каждой стороне соединения. В примере клиента, сеансовый ключ относится к разновидности AES128. Сгенерированный как на стороне программы-клиента, так и на стороне веб-сервера Google, сеансовый ключ на каждой стороне сохраняет конфиденциальность диалога между двумя сторонами. Например, протокол согласования Диффи-Хеллмана позволяет повторять весь процесс PMS, если одна из сторон (например, программа-клиент) или другая (в данном случае веб-сервер Google) требует перезапуск согласования.
Операции OpenSSL, показанные в командной строке, также доступны через API для базовых библиотек. В этих двух статьях выделены утилиты, позволяющие сделать примеры короткими и сосредоточиться на темах криптографии. Если вы интересуетесь вопросами безопасности, OpenSSL — это отличная стартовая площадка.
Если вам интересно посещать бесплатные онлайн-мероприятия по DevOps, Kubernetes, Docker, GitlabCI и др. и задавать вопросы в режиме реального времени, подключайтесь к каналу DevOps by REBRAIN.
*Анонсы мероприятий каждую неделю
Практикумы для специалистов по инфраструктуре и разработчиков — https://rebrainme.com.
Наш Youtube-канал — https://www.youtube.com/channel/UC6uIx64IFKMVmj12gKtSgBQ.
Агентство Fevlake, проектируем и поддерживаем IT-инфраструктуры с 2012 года — https://fevlake.com.
В феврале мировую общественность всколыхнула необычная новость – полиция одного из английских округов Уэст Мидленд выпустила необычную памятку для учителей и родителей.
В ней перечислено несколько известных программ, которые, по мнению полиции, опасны для неокрепших умов и ведут их на кривую дорожку хакерства и киберпреступности:
...
Перевод статьи — https://devops.com/which-desktop-os-is-best-for-devops/
Какую операционную систему лучше использовать инженерам DevOps?
Это вопрос, на который нет однозначного ответа. Разговоры о том, какая ОС «лучше», всегда противоречивы.Я не собираюсь отдавать предпочтение одной операционной системе, когда мы говорим о работе DevOps. Но...
Автор — Сергей Попов
Привет, друзья.
Вот уже полтора месяца я фигачу как полноценный devops engineer (одна штука) в команде разработки. Идет рефакторинг сервиса из монолита в микросервисы с деплоем в кубер. ЯП — GO + postgres + mongo + rabbit + мониторинг и логи.
Команда: 6 разработчиков + я + QA (1 шт). На мне, собственно, k8s на железе,...