Если ваш заказчик решил сделать тестирование на проникновение в своём офисе впервые, то в 9 из 10 случаев ваше общение начнется с: «А протестируйте наш Wi-Fi!». Трудно сказать, почему эта тема до сих пор волнует людей в такой степени. Сегодня мы поговорим о том, что в реальности можно протестировать, и какие инструменты для этого есть.
На протяжении последних пятнадцати лет роботы (RPA – robotic process automation) с успехом решают задачу избавления людей от рутинной работы. Программные роботы способны формировать отчеты, собирать данные, обрабатывать первичные учетные документы, управлять приложениями и т. п. Продукты RPA могут существенно ускорить и удешевить производственные процессы, поэтому число компаний, готовых внедрять программных роботов растет. Однако, с ростом популярности этих решений приходится задумываться об организации их безопасной работы. Программный робот по сути является ПО, за корректностью работы которого нужно следить.
Как правильно подойти к обеспечению информационной безопасности RPA решений – этой теме будет посвящена наша статья. Мы – команда разработки Efros Config Inspector кратко расскажем о своем опыте контроля безопасности RPA.
Модуль контроля
Если говорить в широком смысле, то большинство проблем безопасности RPA можно разделить на два больших блока — это комплаенс-риски и операционные риски.
Комплаенс-риски связаны с нарушением методики управления RPA. Операционные, включают потенциальную возможность неисправности систем, введения ограничений регуляторными органами и другие.
Применяемый нами модуль позволят существенно минимизировать ряд операционных рисков. Модуль, обеспечивает контроль:
- целостности файлов всех компонентов;
- изменения текстовых(читаемых) файлов конфигураций;
- изменения значений реестра;
- изменения прав файлов и папок, а также прав реестра.
Может показаться, что этого уже достаточно для безопасности, но мы пошли дальше и добавили возможность контролировать параметры среды через API, что позволило централизованно отслеживать изменения всех процессов, осуществляемых через платформу автоматизации. Рассмотрим эти возможности подробнее на примере Uipath:
Мы продолжаем цикл материалов о работе в облаках на примере AWS. Итак, вы спланировали переход в облако, посчитали стоимость и оценили риски, и пришла пора согласовать свои действия с ответственными за информационную безопасность, скорее всего безопасники предложат перенести опыт построения классических инфраструктур на облачные реалии и почти наверняка, окажутся не совсем правы. Разберемся почему.
-----------------------------------
Вы можете переместить все, или почти все свои существующие решения в облако. Не сложно сделать образ межсетевого экрана, загрузить и развернуть его в облаке и продолжать работать как раньше, наверняка можно переместить DLP, антивирусы и прочие решения, на которые уже потрачены деньги и лицензии еще не истекли. Но с другой стороны, я бы предложил присмотреться к тем механизмам, которые предлагает сама облачная платформа. Если это не совсем базовый VPS хостинг, где кроме межсетевого экрана, скорее всего, ничего нет, то вы можете попробовать использовать то, что предлагает платформа.
AWS Web Application Firewall (WAF)
Вы наверняка уже используете какое-то решение для защиты веб-сервера, может быть, это NGFW с функциями WAF, возможно, какое-то выделенное решение. В AWS тоже есть свой WAF, который можно развернуть на уровне CloudFront, балансировщике нагрузки или API шлюзе. Делает он примерно то же, что и все другие WAF – вы пишите правила, блокирующие трафик по тем или иным шаблонам, также, есть готовые шаблоны для известных атак, правда, они будут стоить дополнительных денег. Задача стандартная – не допустить вредный трафик на ваш веб-сервер или веб-приложение.
В этой статье руководитель группы защиты инфраструктурных ИТ-решений компании «Газинформсервис» Сергей Полунин рассмотрит два способа управления учётными записями и их правами в облачной среде на примере Amazon Web Services.
Identity and Access Management
Одним из сервисов, отвечающих за безопасность AWS является служба Identity and Access Management (IAM). Именно она обеспечивает триаду – идентификация, аутентификация, авторизация. Обычно при первом знакомстве с IAM рассказывают об обязательном включении многофакторной аутентификации и запрете пользоваться рутом.
Также обязательно упоминают про парольную политику, почти такую же, как в прочих системах, которыми вы уже управляете. Заодно намекают, что с логином и паролем можно зайти только в административный интерфейс, а вот управлять «начинкой» придётся с помощью специально созданных ключей. Все это вопросов не вызывает, примерно этого мы и ожидали, но есть нюансы.
IAM Policy
Управление доступом осуществляется при помощи политик IAM Policy, а правила пишутся в формате JSON и в этот момент начинают закрадываться некоторые сомнения, что легко не будет, потому что придется писать код самостоятельно, а не просто нажимать на кнопки.
Например,
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "FullAccess",
"Effect": "Allow",
"Action": ["s3:*"],
"Resource": ["*"]
}
]
}
Это политика, например, даёт доступ ко всем S3 хранилищам, но запрещает работать с объектами в S3 хранилище my-secure-bucket.
С 16 по 19 мая команда сотрудников «Газинформсервис» принимала участие в кибербитве The Standoff, на стороне защиты. О том, как это было, рассказал участник проекта, Никита Платов инженер-проектировщик группы защиты АРМ и серверов «Газинформсервис».
Полигон
Киберполигон The Standoff – это виртуальная копия города, имитирующая его инфраструктуру – в нем есть банковская система, энергетический сектор, заводы, вокзалы, аэропорты и многое другое. Информационные системы города развернуты на серверах, виртуальных машинах и ПЛК, состояние инфраструктуры в реальном времени отражается на рабочем макете города, расположенном на площадке киберполигона в Москве. На нем можно увидеть некоторые последствия от действий хакеров, например, пожар на макете электростанции.
В первой части статьи мы рассмотрели различные варианты запуска контейнеров в облаке на примере Amazon Web Services. В этом материале мы на практике разберем, как выглядит создание и запуск кластера Elastic Kubernetes Service.
-------------------
Итак, прежде чем начать работу EKS, нам потребуется несколько инструментов:
Пока мы разрабатываем и запускаем своё приложение в Docker Desktop, всё довольно просто и понятно, но, когда приходит время разворачивать его в облаке, вопросов становится существенно больше. Развёртывание даже простого приложения из нескольких контейнеров приходится планировать заранее. Поэтому сегодня мы на примере Amazon Web Services разберем, какие есть варианты для запуска контейнеризированных приложений в облаке и (спойлер!) настроим кластер Kubernetes в AWS двумя разными способами.
Информация актуальна для тех, у кого уже есть подписка на сервисы AWS и для тех, кто верит, что ограничения на подписку новых пользователей не продлятся слишком долго.
Выбираем систему оркестрации
Арендуем сервер, ставим ОС и весь необходимый софт, а затем в него вручную переносим все наши контейнеры, используя виртуальные машины Amazon Elastic Compute Cloud (EC2). Такое решение будет хорошо работать, особенно, если вы прошли курс Kubernetes The Hard Way и хотите применить всё увиденное в реальном проекте. Запретить вам делать это, конечно, невозможно, но, если это ваш первый проект, советую повременить и понабивать шишки в тестовых средах или с какими-нибудь некритичными приложениями. Плюс, выбрав такой путь, мы лишаемся всех бонусов облака. Это будет такая креативная колокация, только сервер вы не купили и принесли в центр обработки данных (ЦОД), а взяли в аренду.
Дальнейший план наших действий будет зависеть от того, какую систему оркестрации мы выберем. В AWS их, по сути, две:
