Очень много вопросов после прочтения. Больше, чем ответов.
Почему, когда контрол-плейн недоступен, "бизнес теряет деньги"? Его приложения не зависят от контрол-плейна.
Почему есть доступ по ssh на мастер узел? Что с безопасностью?
Почему сертификат не обновился самостоятельно? Почему не было алертов за пару недель?
Почему вообще может закончиться место на диске и мониторинг молчит?
Почему бы не перегружать кубелет сколько мне вздумается, ведь логи от предыдущих запусков никуда не денутся.
Начинал читать статью как интересный кейс, а оказалось все для вывода - приходите к нам и мы расскажем как делать правильно.
С другой стороны хорошо что есть такие курсы, и все больше людей начнут делать в итоге правильно. И не придется беспокоиться во вторник в 14:00 о поломке etcd, которая вообще не должна была случиться.
Мысль на тему: ретеншн бэкапов (удаление старых версий бэкапа) в системе бэкапов - это потенциальное зло.
Если бэкап потенциально можно не только создать, но и удалить - это может привести к недоступности бэкапов, в случае ошибки или действий злоумышленника.
Например, вы храните 10 последних резервных копий, а старые версии автоматически удаляются. Если выполнить бэкап невалидных данных 10 раз подряд - у вас не будет ни одной валидной резервной копии.
Nginx ingress controller не формирует конфигурации, где в rewrite есть вопросик "?"
То есть уязвимость скорее формальная, чем реальная.
Исключение составляют configuration snippets, где можно написать что угодно. Но ими и так можно было произвольным образом сломать контроллер, их наличие само по себе можно рассматривать как уязвимость.
Судя по форматированию у вас промпт тоже написан с помощью LLM, или как минимум постобработан.
Отсюда и ожидания, что эти требования сами собой "родятся" при запросе "сделай хорошо". Если моделька может написать требования, а потом выполнить все по требованиям, то почему бы не сделать это за раз?
В самом стронгхолде ансилер в ядре, отдельный менеджер (горутина)
Если запускается в кубернетес, то дискавери по кубовому сервису может быть.
А если на виртуалочках, то в конфиг-файл перечень нод нужно добавить. В этом есть определенный элемент безопасности - чтобы добавить в список распечатки произвольную ноду недостаточно просто исправить конфиг, нужно перезапустить узел и распечатать его.
1) Да, так. Подробнее про это написано тут. Ну только не на почту отправляет, просто в файл сохраняется, а дальше можете делать с этим что угодно, в том числе отправить на почту.
2) Вообще в этом и смысл. Чтобы "кто угодно" не мог заменить ключи. То есть да, для ротации ключей нужен частичный набор предыдущих ключей.
3) Зависит от требований. Мы используем и auto-unseal и ручной. Из интересных решений именно в нашем продукте (в отличие от Vault CE) - поддерживается auto-unseal например через Рутокен или Яндекс-облако (можно почитать тут и тут). А еще есть режим, когда ноды одного кластера сами друг друга распечатывают.
То есть отвечая на вопрос про "процессы доставки unseal ключей ответственным сотрудникам".
Вариант 1: Инициализация с шифрованием ключей через PGP. Ключи копируются в S3, закрытые ключи от них находятся у ответственных сотрудников.
Вариант 2: физический токен вставлен в сервер. В этом случае unseal-ключей как таковых нет, есть recovery-ключи, которые позволяют восстановить рут-токен, но не расшифровать данные. Recovery-ключи тоже могут быть зашифрованы PGP
Вариант 3: вообще нет Recovery-ключей, unseal через токен, управление через git.
Хорошо что он не задался вопросом почему эти инциденты происходят и что нужно пофиксить, чтобы они не происходили.
Потом сделать обратную связь - инцидент, разбор, фикс. В итоге нет аварий в продакшне - профит. А может и нет, и вместо этого есть огромный объем кода, который только и делает, что обрабатывает корнер-кейсы.
Есть довольно много, ПО где под капотом не OpenSSL. Например, практически все приложения на go, там своя реализация crypto, не обёртка над openssl. Аналогично, приложения на Java используют JSSE.
Ну и для С существуют альтернативные варианты, например тот же chrome использует BoringSSL. В IoT популярен WolfSSL.
агент сам собирает отчеты, выявляет ключевые риски, готовит договор с правками, презентацию и финальный меморандум
Для кого агент делает презентацию и меморандум? С таким подходом люди не должны читать все это - оно должно машинно-обрабатываться.
И откуда берется договор до правок? Его сделал другой ИИ? Почему там понадобились какие-то правки, моделька была не очень эффективная?
Дальше - больше. Юрист в суде. Суды конечно же нужно заменить на ИИ. Они тоже будут работать эффективнее. Одно дело за 1.5 часа, не больше, и сколько угодно параллельных дел, просто строй датацентры. Юрист там вроде бы и не нужен, агенты "судьи" сами соберут необходимые данные. Как в фильме Mercy
Ну то, что Минцифры борется с доступностью защищённых сетей - это может нормально.
Но когда это делает Министерство цифрового развития, связи и массовых коммуникаций РФ, то уже странно. Борьба со связью и развитием как будто противоречит названию.
В США например переименовали "Министерство обороны" в "Министерство войны". Звучит вроде дико, но ведь сейчас в США это министерство занимается именно войной.
Может имело бы смысл назвать "Министерство цифрового развития, связи и массовых коммуникаций" какой-то вроде "Министерства ограничения цифрового развития, блокировки связи и контроля за массовыми коммуникациями", чтобы по названию было более понятно направление деятельности. Судя по методическим указаниям, которое выпускает министерство - деятельность связана с блокировкой и контролем.
А то что такое Минцифры - непонятно. Цифрами занимается? Возможно это от "МинЦифРа" - "Министерство Цифрового Развития". Но тогда склонять не нужно.
Ситуация, описанная вами, для клиента конечно выглядит неприятно.
Но если погрузиться чуть глубже, то можно найти объяснение. Например, если при аварии датацентр недоступен, то это не значит, что ресурсы там не запущены. Ваши вм-ки наверняка продолжают там работать, только управление ими не работает. Вам, как пользователю, это конечно не интересно (ну кроме случаев, когда у вас кластерные решения и вы вынуждены думать о потенциальном сплитбрейне). Но это вполне себе реальная причина, почему ресурсы в недоступном датацентре считаются в квотах. Пока не доказано, что они были выключены - они считаются включенными.
Представьте ситуацию, что произошел разрыв связи, и вы запустили +100 узлов в другом датацентре. А когда связь восстановилась, то оказалось, что у вас запущено 200 узлов. При квоте в 100. Вы выключили 50, но все равно не можете запустить 1 узел.
Так что в описанной вами ситуации хорошего решения возможно нет. Оба со своими нюансами.
На самом деле много кому было бы не интересно "изучать законодательство в части требований ФСБ к СКЗИ и ФСТЭК к ГИС, КИИ", которые сплошь и рядом имеют двоякое толкование или просто неоднозначности. Вместо этого нужна какая-то уверенность в том, если "я сделаю так и вот так" (к примеру, перейду на использование ГОСТ VPN) то какие-то из этих требований будут выполняться. То есть если мы говорим про защиту канала передачи - у аудитора не возникнет вопрос, почему часть трафика между узлами не защищено после внерения ГОСТ VPN. Если вопрос возникает, то внедрение VPN мало помогает, может быть нужно смотреть в сторону сквозного шифрования.
Есть ли какой-то сертификат соответствия вашей схемы подключения?
Смущает такой момент - между клиентом и шлюзом устанавливается защищённое соединение с помощью ГОСТ. Но, судя по схеме, после терминации на аппаратном шлюзе трафик выходит в сеть Селектел, где перемешивается с трафиком других пользователей. У которых может быть свой VPN. Или вообще может не быть VPN.
Что, кажется, противоречит идее virtual private network - ГОСТ-ом защищена не сеть, а какой-то кусочек на пути следования пакетов. Вырожденный случай - можно на локалхосте клиента пропихивать трафик через VPN, а дальше отправлять по обычным каналам, это же не добавляет нам защиту. Если бы мы считали, что с обоих концов шлюза сеть одной компании - то вопросов кажется нет. Но на одной стороне мультетенантная сеть, а транспорт между клиентами закрыт ГОСТ-ом только на половину.
Думаю многие согласятся, что на данный момент внедрение ГОСТ алгоритмов шифрования проводится компаниями не для обеспечения повышенной безопасности, а для соответствия требованиям законодательства. Так вот, как проверяющие органы относятся к тому, что трафик, прошедший через ГОСТ VPN внутри сети Селектел не защищён ГОСТ VPN? Есть ли какие-то подтверждения, что такой подход действительно "православный"?
Ну не обязательно тераформом. Зачем нужен какой-то кусок кластера, который менеджится не так, как остальные ноды?
Это может быть какая-то виртуалка в облаке, которая потом уничтожается. Или докер -контейнер на машине того, кто проводит инсталляцию. Или бинарь/скрипт, который дёргает ручки api до того момента, когда кластер поднимется, и начнет дергать ручки сам
А что происходит с линиями, которые выпускали, скажем так, предыдущие поколения памяти ddr ddr2 ddr3? Модернизируют безвозвратно? Потому что спроса на старую память нет? Или они за 2-3 года производства изнашиваются в ноль, так, что эксплуатировать невозможно?
Просто для огромного количества продуктов потребительского сегмента вполне подошла бы старая память. Да, там есть проблемы с тем, что для старой памяти нужны старые контроллеры, которые тоже сняты с производства. А под них возможно нужен старый код каких-то библиотек, потому что новый может работать только на новом железе.
Но условные стиральные машинки или мультимедиа автомобилей вполне могли бы работать на чипах (в том числе и памяти) десятилетней давности. Просто их вероятно никто не производит.
Очень много вопросов после прочтения. Больше, чем ответов.
Почему, когда контрол-плейн недоступен, "бизнес теряет деньги"? Его приложения не зависят от контрол-плейна.
Почему есть доступ по ssh на мастер узел? Что с безопасностью?
Почему сертификат не обновился самостоятельно? Почему не было алертов за пару недель?
Почему вообще может закончиться место на диске и мониторинг молчит?
Почему бы не перегружать кубелет сколько мне вздумается, ведь логи от предыдущих запусков никуда не денутся.
Начинал читать статью как интересный кейс, а оказалось все для вывода - приходите к нам и мы расскажем как делать правильно.
С другой стороны хорошо что есть такие курсы, и все больше людей начнут делать в итоге правильно. И не придется беспокоиться во вторник в 14:00 о поломке etcd, которая вообще не должна была случиться.
Например S3 банкет с доступом только на запись (put), без delete
Удаление по ретеншену бакета
Мысль на тему: ретеншн бэкапов (удаление старых версий бэкапа) в системе бэкапов - это потенциальное зло.
Если бэкап потенциально можно не только создать, но и удалить - это может привести к недоступности бэкапов, в случае ошибки или действий злоумышленника.
Например, вы храните 10 последних резервных копий, а старые версии автоматически удаляются. Если выполнить бэкап невалидных данных 10 раз подряд - у вас не будет ни одной валидной резервной копии.
Nginx ingress controller не формирует конфигурации, где в rewrite есть вопросик "?"
То есть уязвимость скорее формальная, чем реальная.
Исключение составляют configuration snippets, где можно написать что угодно. Но ими и так можно было произвольным образом сломать контроллер, их наличие само по себе можно рассматривать как уязвимость.
Очевидная польза от статей про ИИ - они выдавили статьи про блокчейн, а точнее про очередной-коин.
У ИИ есть хотя бы прикладное применение, в отличие от коинов.
Судя по форматированию у вас промпт тоже написан с помощью LLM, или как минимум постобработан.
Отсюда и ожидания, что эти требования сами собой "родятся" при запросе "сделай хорошо". Если моделька может написать требования, а потом выполнить все по требованиям, то почему бы не сделать это за раз?
В самом стронгхолде ансилер в ядре, отдельный менеджер (горутина)
Если запускается в кубернетес, то дискавери по кубовому сервису может быть.
А если на виртуалочках, то в конфиг-файл перечень нод нужно добавить. В этом есть определенный элемент безопасности - чтобы добавить в список распечатки произвольную ноду недостаточно просто исправить конфиг, нужно перезапустить узел и распечатать его.
1) Да, так. Подробнее про это написано тут. Ну только не на почту отправляет, просто в файл сохраняется, а дальше можете делать с этим что угодно, в том числе отправить на почту.
2) Вообще в этом и смысл. Чтобы "кто угодно" не мог заменить ключи. То есть да, для ротации ключей нужен частичный набор предыдущих ключей.
3) Зависит от требований. Мы используем и auto-unseal и ручной. Из интересных решений именно в нашем продукте (в отличие от Vault CE) - поддерживается auto-unseal например через Рутокен или Яндекс-облако (можно почитать тут и тут). А еще есть режим, когда ноды одного кластера сами друг друга распечатывают.
То есть отвечая на вопрос про "процессы доставки unseal ключей ответственным сотрудникам".
Вариант 1: Инициализация с шифрованием ключей через PGP. Ключи копируются в S3, закрытые ключи от них находятся у ответственных сотрудников.
Вариант 2: физический токен вставлен в сервер. В этом случае unseal-ключей как таковых нет, есть recovery-ключи, которые позволяют восстановить рут-токен, но не расшифровать данные. Recovery-ключи тоже могут быть зашифрованы PGP
Вариант 3: вообще нет Recovery-ключей, unseal через токен, управление через git.
Хорошо что он не задался вопросом почему эти инциденты происходят и что нужно пофиксить, чтобы они не происходили.
Потом сделать обратную связь - инцидент, разбор, фикс. В итоге нет аварий в продакшне - профит. А может и нет, и вместо этого есть огромный объем кода, который только и делает, что обрабатывает корнер-кейсы.
Есть довольно много, ПО где под капотом не OpenSSL. Например, практически все приложения на go, там своя реализация crypto, не обёртка над openssl. Аналогично, приложения на Java используют JSSE.
Ну и для С существуют альтернативные варианты, например тот же chrome использует BoringSSL. В IoT популярен WolfSSL.
Ну выше пишут, что "поддержка AES должена быть выпилена совсем". Очевидно, что в OpenSSL она не выпилена.
Поэтому вопрос - где и как это регламентируется. И проверяется. И кем. Потому что сейчас выглядит так, что везде очень по разному.
Просто OpenSSL предоставляет возможность работать с RSA, AES и SHA, а в России нужно ГОСТ 34.10, ГОСТ 34.12 и ГОСТ 34.11 вместо этого.
Еще в OpenSSL есть TLS, но этот TLS не умеет работать с ГОСТ.
И с одной стороны все как будто пользуются OpenSSL, а как будто им пользоваться невозможно, потому что не православно.
В России есть какие-то ограничения на использование криптографии из OpenSSL? Или наоборот, требования?
Допустим, я хочу безопасно передать сообщение по открытым каналам связи. Для этого я могу:
Зашифровать сообщение с помощью openssl на своей ubuntu (например, AES256, потому что openssl ГОСТ не умеет, а тот что умеет - не сертифицирован)
Зашифровать сообщение с помощью openssl на Astra SE
Зашифровать сообщение с помощью Crypto Pro на своей Ubuntu (например, ГОСТ 34.12)
Зашифровать сообщение на Astra SE с помощью Crypto Pro
В каких случаях мне достаточно любого из вариантов, а в каких некоторые не подходят? В чем разница?
Для кого агент делает презентацию и меморандум? С таким подходом люди не должны читать все это - оно должно машинно-обрабатываться.
И откуда берется договор до правок? Его сделал другой ИИ? Почему там понадобились какие-то правки, моделька была не очень эффективная?
Дальше - больше. Юрист в суде. Суды конечно же нужно заменить на ИИ. Они тоже будут работать эффективнее. Одно дело за 1.5 часа, не больше, и сколько угодно параллельных дел, просто строй датацентры. Юрист там вроде бы и не нужен, агенты "судьи" сами соберут необходимые данные. Как в фильме Mercy
Ну то, что Минцифры борется с доступностью защищённых сетей - это может нормально.
Но когда это делает Министерство цифрового развития, связи и массовых коммуникаций РФ, то уже странно. Борьба со связью и развитием как будто противоречит названию.
В США например переименовали "Министерство обороны" в "Министерство войны". Звучит вроде дико, но ведь сейчас в США это министерство занимается именно войной.
Может имело бы смысл назвать "Министерство цифрового развития, связи и массовых коммуникаций" какой-то вроде "Министерства ограничения цифрового развития, блокировки связи и контроля за массовыми коммуникациями", чтобы по названию было более понятно направление деятельности. Судя по методическим указаниям, которое выпускает министерство - деятельность связана с блокировкой и контролем.
А то что такое Минцифры - непонятно. Цифрами занимается? Возможно это от "МинЦифРа" - "Министерство Цифрового Развития". Но тогда склонять не нужно.
Ситуация, описанная вами, для клиента конечно выглядит неприятно.
Но если погрузиться чуть глубже, то можно найти объяснение. Например, если при аварии датацентр недоступен, то это не значит, что ресурсы там не запущены. Ваши вм-ки наверняка продолжают там работать, только управление ими не работает. Вам, как пользователю, это конечно не интересно (ну кроме случаев, когда у вас кластерные решения и вы вынуждены думать о потенциальном сплитбрейне). Но это вполне себе реальная причина, почему ресурсы в недоступном датацентре считаются в квотах. Пока не доказано, что они были выключены - они считаются включенными.
Представьте ситуацию, что произошел разрыв связи, и вы запустили +100 узлов в другом датацентре. А когда связь восстановилась, то оказалось, что у вас запущено 200 узлов. При квоте в 100. Вы выключили 50, но все равно не можете запустить 1 узел.
Так что в описанной вами ситуации хорошего решения возможно нет. Оба со своими нюансами.
Опять более 11 лет? Ну так-то спору нет, просто пора бы писать "более 30 лет", ведь первый релиз был в начале 1996 года, а создаётся он ещё дольше.
требованиям "ФСБ к СКЗИ и ФСТЭК к ГИС, КИИ"
На самом деле много кому было бы не интересно "изучать законодательство в части требований ФСБ к СКЗИ и ФСТЭК к ГИС, КИИ", которые сплошь и рядом имеют двоякое толкование или просто неоднозначности. Вместо этого нужна какая-то уверенность в том, если "я сделаю так и вот так" (к примеру, перейду на использование ГОСТ VPN) то какие-то из этих требований будут выполняться. То есть если мы говорим про защиту канала передачи - у аудитора не возникнет вопрос, почему часть трафика между узлами не защищено после внерения ГОСТ VPN. Если вопрос возникает, то внедрение VPN мало помогает, может быть нужно смотреть в сторону сквозного шифрования.
Есть ли какой-то сертификат соответствия вашей схемы подключения?
Смущает такой момент - между клиентом и шлюзом устанавливается защищённое соединение с помощью ГОСТ. Но, судя по схеме, после терминации на аппаратном шлюзе трафик выходит в сеть Селектел, где перемешивается с трафиком других пользователей. У которых может быть свой VPN. Или вообще может не быть VPN.
Что, кажется, противоречит идее virtual private network - ГОСТ-ом защищена не сеть, а какой-то кусочек на пути следования пакетов. Вырожденный случай - можно на локалхосте клиента пропихивать трафик через VPN, а дальше отправлять по обычным каналам, это же не добавляет нам защиту. Если бы мы считали, что с обоих концов шлюза сеть одной компании - то вопросов кажется нет. Но на одной стороне мультетенантная сеть, а транспорт между клиентами закрыт ГОСТ-ом только на половину.
Думаю многие согласятся, что на данный момент внедрение ГОСТ алгоритмов шифрования проводится компаниями не для обеспечения повышенной безопасности, а для соответствия требованиям законодательства. Так вот, как проверяющие органы относятся к тому, что трафик, прошедший через ГОСТ VPN внутри сети Селектел не защищён ГОСТ VPN? Есть ли какие-то подтверждения, что такой подход действительно "православный"?
Ну не обязательно тераформом. Зачем нужен какой-то кусок кластера, который менеджится не так, как остальные ноды?
Это может быть какая-то виртуалка в облаке, которая потом уничтожается. Или докер -контейнер на машине того, кто проводит инсталляцию. Или бинарь/скрипт, который дёргает ручки api до того момента, когда кластер поднимется, и начнет дергать ручки сам
А что происходит с линиями, которые выпускали, скажем так, предыдущие поколения памяти ddr ddr2 ddr3? Модернизируют безвозвратно? Потому что спроса на старую память нет? Или они за 2-3 года производства изнашиваются в ноль, так, что эксплуатировать невозможно?
Просто для огромного количества продуктов потребительского сегмента вполне подошла бы старая память. Да, там есть проблемы с тем, что для старой памяти нужны старые контроллеры, которые тоже сняты с производства. А под них возможно нужен старый код каких-то библиотек, потому что новый может работать только на новом железе.
Но условные стиральные машинки или мультимедиа автомобилей вполне могли бы работать на чипах (в том числе и памяти) десятилетней давности. Просто их вероятно никто не производит.