В самом стронгхолде ансилер в ядре, отдельный менеджер (горутина)
Если запускается в кубернетес, то дискавери по кубовому сервису может быть.
А если на виртуалочках, то в конфиг-файл перечень нод нужно добавить. В этом есть определенный элемент безопасности - чтобы добавить в список распечатки произвольную ноду недостаточно просто исправить конфиг, нужно перезапустить узел и распечатать его.
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 года производства изнашиваются в ноль, так, что эксплуатировать невозможно?
Просто для огромного количества продуктов потребительского сегмента вполне подошла бы старая память. Да, там есть проблемы с тем, что для старой памяти нужны старые контроллеры, которые тоже сняты с производства. А под них возможно нужен старый код каких-то библиотек, потому что новый может работать только на новом железе.
Но условные стиральные машинки или мультимедиа автомобилей вполне могли бы работать на чипах (в том числе и памяти) десятилетней давности. Просто их вероятно никто не производит.
Лет 5 назад пользовался провайдером tf для proxmox, было терпимо. Провайдер виртуалки нарезал, диски ширил, даже мигрировал между гиперами. Были некоторые моменты, связанные с тем, что кластер из Проксмоксов - не совсем "кластер", а все же набор гиперов, между которыми виртуалочки нужно переносить. Несколько мешала эта "прибитость" машины к гиперу. Если я через UI мигрировал виртуалку, то тераформ надо было править, и стейт синкать. Но с тех пор проксмокс развился, появились ресурс пулы и SDN. Так что "ну почти VSphere для бедных". Или для гиков. Ну и попроще, чем openstack.
Прям в сердечко. Когда мне было года 4 я залез за радиолу. И видимо испугался, когда не смог вылезти, и толкнул ее перед собой (а может быть испугался потом, когда она упала, или когда родители прибежали). Эта картинка у меня в памяти прям отпечаталась - я стою в углу комнаты, передо мной лежит лицом вниз радиола, а с той стороны стоят папа с мамой, прибежавшие на грохот из соседней комнаты. Итог - у радиолы разбитое стекло (была ли бита моя попа - я не помню).
Это мучило меня много лет. Даже потом, когда радиола была уже совсем не современной и переехала на дачу скорее как подставка под цветок, чем как радиоприемник, любой взгляд на разбитое стекло навевал на меня печаль.
И вот, в возрасте лет 14-15 я похоже стал достаточно самостоятельным, настолько, что нашел какую-то радиомастерскую, и купил там новое (во всяком случае - целое) стекло для Ригонды. И сам его поменял.
Детский гештальт был закрыт. И теперь эта история с разбитым стеклом у Ригонды меня не печалит, а даже наоборот - вызывает теплые воспоминания.
И немного подкручпнный мониторинг (он там есть, довольно расширяемый, только по умолчанию все довольно убого настроено)
И получаем бОльшую часть того, что вы описали, где-то чуть больше, где-то чуть меньше.
Правда там начинаются другие проблемы. Если с kubernetes на "вы", то все может быть сложно, непонятно. И самое страшное - непонятно что делать, если сломалось. Но так можно про что угодно сказать.
Согласен, что хорошо бы иметь для подстраховки людей, которым точно понятно что делать, когда вам уже ничего непонятно. И наверное как раз за это стоит платить.
Собственно самое интересное начинается с момента, когда ломается то, что вроде бы должно было не ломаться.
У меня есть каверзные вопросы в этом плане - что входит в 85%? Где это зафиксировано?
Давайте придумаем какой-то искусственный кейс.
Например я развернул HA кластер в облаке. А потом начал в нем очень интенсивно апдейтить строки. С точки зрения неискушенного пользователя - количество данных не увеличивается. С точки зрения postgres - появляется огромное количество WAL. Что может привести, например:
к окончанию места на диске под WAL
к тому, что WAL не успевает архивироваться или выгружаться в S3 (если такое есть)
к тому, что реплики отстают
к тому, что невозможно сделать консистентный фулл-бэкап, потому что пока вы копируете WAL - появляются новые WAL
С точки зрения пользователя он делает легитимные операции с БД - апдейтит строку в таблице из одной строки. Да, часто, но почему бы и нет? С точки зрения инфраструктуры и репликации постргеса - такие действия приводят к реальным проблемам.
Так вот, кто получает алерты, что, например, WAL не успевают реплицироваться? И как решаются такие ситуации в целом? Кластер ломается потому что место кончилось? Ваши инженеры бегут добавляют место под WAL? Уведомляете клиента что у него уже сломалось? Или что у него вот-вот сломается потому что он активно пишет? А может вы запрещаете делать асинхронные кластера, чтобы всегда была синхронная репликация, и WAL точно доезжали? Начинаете тротлить запросы? А должен ли пользователь Managed Postgres вообще знать что-то про WAL?
Я уже молчу про классику вроде "я купил тут самый жирный вариант инсталляции, но у меня запрос все равно работает медленно, наверное у вас что-то не так с ..." и далее на выбор: инстансом, с дисками, с iops, с сетью, плохая версия посгреса, вы оверселите ... Погружаетесь в запрос, или просто даете ссылку на свой мониторинг, пусть он ему верит?
В самом стронгхолде ансилер в ядре, отдельный менеджер (горутина)
Если запускается в кубернетес, то дискавери по кубовому сервису может быть.
А если на виртуалочках, то в конфиг-файл перечень нод нужно добавить. В этом есть определенный элемент безопасности - чтобы добавить в список распечатки произвольную ноду недостаточно просто исправить конфиг, нужно перезапустить узел и распечатать его.
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 года производства изнашиваются в ноль, так, что эксплуатировать невозможно?
Просто для огромного количества продуктов потребительского сегмента вполне подошла бы старая память. Да, там есть проблемы с тем, что для старой памяти нужны старые контроллеры, которые тоже сняты с производства. А под них возможно нужен старый код каких-то библиотек, потому что новый может работать только на новом железе.
Но условные стиральные машинки или мультимедиа автомобилей вполне могли бы работать на чипах (в том числе и памяти) десятилетней давности. Просто их вероятно никто не производит.
Лет 5 назад пользовался провайдером tf для proxmox, было терпимо. Провайдер виртуалки нарезал, диски ширил, даже мигрировал между гиперами. Были некоторые моменты, связанные с тем, что кластер из Проксмоксов - не совсем "кластер", а все же набор гиперов, между которыми виртуалочки нужно переносить. Несколько мешала эта "прибитость" машины к гиперу. Если я через UI мигрировал виртуалку, то тераформ надо было править, и стейт синкать.
Но с тех пор проксмокс развился, появились ресурс пулы и SDN. Так что "ну почти VSphere для бедных". Или для гиков. Ну и попроще, чем openstack.
Мы же Кубернетес там на виртуалочках запускаем? Тогда может сразу сюда https://github.com/k8s-proxmox/cloud-provider-proxmox ?
Прям в сердечко.
Когда мне было года 4 я залез за радиолу. И видимо испугался, когда не смог вылезти, и толкнул ее перед собой (а может быть испугался потом, когда она упала, или когда родители прибежали). Эта картинка у меня в памяти прям отпечаталась - я стою в углу комнаты, передо мной лежит лицом вниз радиола, а с той стороны стоят папа с мамой, прибежавшие на грохот из соседней комнаты. Итог - у радиолы разбитое стекло (была ли бита моя попа - я не помню).
Это мучило меня много лет. Даже потом, когда радиола была уже совсем не современной и переехала на дачу скорее как подставка под цветок, чем как радиоприемник, любой взгляд на разбитое стекло навевал на меня печаль.
И вот, в возрасте лет 14-15 я похоже стал достаточно самостоятельным, настолько, что нашел какую-то радиомастерскую, и купил там новое (во всяком случае - целое) стекло для Ригонды. И сам его поменял.
Детский гештальт был закрыт. И теперь эта история с разбитым стеклом у Ригонды меня не печалит, а даже наоборот - вызывает теплые воспоминания.
На фото блок с батареями прямо на улице. Понятно, что это прототип, но исполнение совсем не уличное. А если вдруг дождь?
Мне почему-то показалось, что вода первым делом будет попадать в место подключения батареи к инвертору (в разъем)
Ну рутину допустим убирает установка cnpg operator, одной строкой
И немного подкручпнный мониторинг (он там есть, довольно расширяемый, только по умолчанию все довольно убого настроено)
И получаем бОльшую часть того, что вы описали, где-то чуть больше, где-то чуть меньше.
Правда там начинаются другие проблемы. Если с kubernetes на "вы", то все может быть сложно, непонятно. И самое страшное - непонятно что делать, если сломалось. Но так можно про что угодно сказать.
Согласен, что хорошо бы иметь для подстраховки людей, которым точно понятно что делать, когда вам уже ничего непонятно. И наверное как раз за это стоит платить.
Собственно самое интересное начинается с момента, когда ломается то, что вроде бы должно было не ломаться.
У меня есть каверзные вопросы в этом плане - что входит в 85%? Где это зафиксировано?
Давайте придумаем какой-то искусственный кейс.
Например я развернул HA кластер в облаке. А потом начал в нем очень интенсивно апдейтить строки. С точки зрения неискушенного пользователя - количество данных не увеличивается. С точки зрения postgres - появляется огромное количество WAL. Что может привести, например:
к окончанию места на диске под WAL
к тому, что WAL не успевает архивироваться или выгружаться в S3 (если такое есть)
к тому, что реплики отстают
к тому, что невозможно сделать консистентный фулл-бэкап, потому что пока вы копируете WAL - появляются новые WAL
С точки зрения пользователя он делает легитимные операции с БД - апдейтит строку в таблице из одной строки. Да, часто, но почему бы и нет?
С точки зрения инфраструктуры и репликации постргеса - такие действия приводят к реальным проблемам.
Так вот, кто получает алерты, что, например, WAL не успевают реплицироваться? И как решаются такие ситуации в целом? Кластер ломается потому что место кончилось? Ваши инженеры бегут добавляют место под WAL? Уведомляете клиента что у него уже сломалось? Или что у него вот-вот сломается потому что он активно пишет? А может вы запрещаете делать асинхронные кластера, чтобы всегда была синхронная репликация, и WAL точно доезжали? Начинаете тротлить запросы? А должен ли пользователь Managed Postgres вообще знать что-то про WAL?
Я уже молчу про классику вроде "я купил тут самый жирный вариант инсталляции, но у меня запрос все равно работает медленно, наверное у вас что-то не так с ..." и далее на выбор: инстансом, с дисками, с iops, с сетью, плохая версия посгреса, вы оверселите ... Погружаетесь в запрос, или просто даете ссылку на свой мониторинг, пусть он ему верит?