Dss сертификат что это

Как выпустить новую электронную подпись вместо Контур.Сертификата

Инструкция для тех, кто перевыпускает Контур.Сертификат.

Контур.Сертификата больше нет

Удобен, как Контур.Сертификат, только отправку отчёта надо подтверждать не с помощью СМС, а через мобильное приложение.

Достаточно установить приложение myDSS на телефон и привязать к нему свою электронную подпись. Каждый раз, когда вы будете отправлять отчёт из Эльбы, в приложение будет приходить запрос на подтверждение отправки. Вы соглашаетесь — отчёт из Эльбы отправляется. Для этого вам нужен телефон на iOS или Android с доступом в интернет.

Чтобы выпустить сертификат DSS, в задаче по выпуску подписи нажмите «У меня есть телефон на iOS или Android‎» и следуйте инструкции.

Подпись на носителе

Такой сертификат нужно установить в реестр компьютера или на флэшку. Подойдёт тем, кто планирует пользоваться подписью на Госуслугах, nalog.ru и других сервисах.

Чтобы установить электронную подпись на носителе, нажмите в задаче на ссылку «У меня нет подходящего телефона».

Разница между DSS и подписью на носителе

Если ещё не определились с типом подписи, посмотрите таблицу ниже:

Подпись на носителе

Где хранится подпись

На нашем сервере, но доступ к ней — только с вашего мобильного телефона

компьютер или флэшка

только iOS не ниже 8.0 версии или Android не ниже 4.0 версии

удобнее работать на Windows, чем на Mac, потому что на Mac сложно установить специальное ПО для подписи

— пока телефон рядом, сможете отправить отчёт с любого компьютера или мобильного;
— если потеряете телефон или забудете пароль, то восстановите доступ к подписи без перевыпуска.

— пока на компьютере установлена подпись/вставлена флэшка с подписью, отчёт отправляется без дополнительного подтверждения;
— можно использовать в сервисах других компаний (на сайте налоговой, Госуслуг).

если телефон без доступа к интернету, то отчёт отправить не получится

— если потеряете флэшку с подписью, то придётся её перевыпускать;

— если установили подпись на компьютер, то будете к нему привязаны;

— не получится отправить отчёт с телефона.

Статья актуальна на 01.02.2021

Получайте новости и обновления Эльбы

Подписываясь на рассылку, вы соглашаетесь на обработку персональных данных и получение информационных сообщений от компании СКБ Контур

Источник

Сертификация PCI DSS: Что это и с чем её едят

Последнее время Visa и MasterCard начали требовать от торговых предприятий и поставщиков услуг, работающих с карточными данными, соответствия стандарту PCI DSS. В этой связи вопрос требований этого стандарта становится важным не только для крупных игроков на рынке, но и для небольших торгово-сервисных предприятий.

Стандарт PCI DSS был разработан Советом по стандартам безопасности данных индустрии платежных карт PCI SSC (Payment Card Industry Security Standards Council) и регламентирует определенный перечень требований к обеспечению безопасности данных платежных карт (ДПК), которые затрагивают как техническую, так и организационную сторону организаций.

В первую очередь стандарт определяет требования к организациям, в информационной инфраструктуре которых хранятся, обрабатываются или передаются данные платёжных карт, а также к организациям, которые могут влиять на безопасность этих данных. Начиная с середины 2012 года все организации, вовлечённые в процесс хранения, обработки и передачи ДПК должны соответствовать требованиям, определяемым PCI DSS, и компании на территории Российской Федерации не являются исключением.

Чтобы понять, необходимо ли вашей компании соблюдать требования стандарта PCI DSS, следует ответить на два главных вопроса: хранятся, обрабатываются или передаются ли данные платежных карт в вашей организации? И могут ли бизнес-процессы вашей организации повлиять на безопасность этих платежных карт? Если ответ на оба вопроса отрицательный, то сертифицироваться по PCI DSS нет нужды.

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

Существуют различные способы подтверждения соответствия требованиям стандарта PCI DSS, которые заключаются в проведении внешнего аудита (QSA), внутреннего аудита (ISA) или проведении организацией самооценки (SAQ).

Внешний аудит QSA выполняется внешней аудиторской организацией, сертифицированной Советом PCI SSС. В ходе проверки аудиторы собирают свидетельства выполнения требований стандарта и сохраняют их на период длительностью в три года.

Внутренний аудит ISA выполняется внутренним, прошедшим обучение и сертифицированным по программе Совета PCI SSC, аудитором. Что касается самооценки SAQ, то она выполняется самостоятельно путём заполнения листа самооценки. В этом случае сбор свидетельств выполнения требований стандарта не требуется.

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

Торгово-сервисное предприятие является организацией, принимающей для оплаты товаров и услуг платежные карты (магазины, рестораны, интернет-магазины и другие).

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

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

По классификации Visa и MasterCard организация будет относиться к уровню 3. Следовательно, для подтверждения соответствия PCI DSS нужно проведение ежеквартального внешнего сканирования уязвимостей компонентов информационной инфраструктуры ASV (Approved Scanning Vendor) и ежегодной самооценки SAQ.

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

PCI DSS-хостинг – это услуга, обеспечивающая безопасное обращение платежных карт для организаций, разместивших свою инфраструктуру на стороне сертифицированного PCI DSS хостинг-провайдера, внутри которой хранятся, обрабатываются или передаются данные платежных карт.

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

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

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

Источник

PCI DSS – как и зачем получать сертификат соответствия

Привет, %username%!
Этот пост мы подготовили для тех, кто работает в сфере интернет-коммерции и планирует принимать (или уже принимает) платежи на собственном сайте. Мы расскажем о международном стандарте безопасности данных PCI DSS. Поговорим о его основных требованиях к информационной инфраструктуре, которая обеспечивает обработку и обеспечение безопасности данных банковских карт. Также мы рассмотрим основные причины прохождения сертификации и возможности, которые получает сертифицированная компания.

PCI DSS (Payment Card Industry Data Security Standard) — стандарт безопасности данных индустрии платежных карт. Стандарт разработан международными платежными системами Visa и MasterCard. Любая организация, планирующая принимать и обрабатывать данные банковских карт на своем сайте, должна соответствовать требованиям PCI DSS.

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

На стадии построения и отладки анти-фрод системы много времени «съест» сбор и анализ данных об операциях по банковским картам. Цель сбора данных – выявление отличительных признаков мошеннических операций. В процессе сбора статистики компании придется столкнуться с большим объемом «charge-back» операций.

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

Стоит отметить, что в мониторинге рисков сложно найти лучшего поставщика услуг, чем процессинговый центр. Благодаря разнообразию и значительному количеству клиентов, ПЦ обладает обширной историей мониторинга и фильтрации. Даже если компания занимается построением собственной анти-фрод системы, она может отдавать на обработку в ПЦ транзакции, вызывающие сомнения у внутренних специалистов по рискам.

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

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

К компаниям, работающим только с платёжным шлюзом и не принимающих на своем данных банковских карт клиентов, относятся только требования департамента рисков платежного шлюза (ПЦ). Они касаются сайта предприятия e-commerce, корректности контента и ценовых предложений, организационной формы компании.

Если после прочтения этого поста у Вас появились вопросы – пишите в комментарии. Со стороны аудитора и специалиста по требованиям стандарта PCI DSS Вас проконсультирует Евгений Безгодов aka Bezgodov, исполнительный директор компании Deiteriy, CISA, PCI QSA. Со стороны платежного шлюза как всегда на связи специалисты процессингового центра PayOnline.

Источник

Как пройти сертификацию PCI DSS: опыт ИТ-ГРАД

В одном из прошлых постов мы отметили, что успешно ресертифицировали свою инфраструктуру по PCI DSS и рассказали о видах хостинга PCI DSS: co-location, IaaS Basic и IaaS Advanced. Сегодня мы подробнее поговорим о самом процессе сертификации и собственном опыте прохождения аудита.

Кому нужно проходить сертификацию

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

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

Далее мы расскажем, как проходил этот процесс.

Этап 1: подготовка документации

Перед тем как пройти аудит, компания должна подготовить нормативно-распорядительные документы по ИБ (инструкции, регламенты, политики). На момент первой сертификации большинство из них уже были нами разработаны, но некоторые все же пришлось дорабатывать.

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

Отметим, что все документы нужно пересматривать и корректировать ежегодно. Особенно если были изменения в ИТ-структуре компании.

Этап 2: построение ИТ-инфраструктуры

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

Для этого нам пришлось организовать отдельную инфраструктуру с выделенной сетью, развернуть серверы ESX, vSphere и vCenter, установить свитчи и сетевой экран, чтобы предотвратить атаки злоумышленников. Всё это оборудование мы задублировали, а затем составили схемы сервисов, сети и бизнес-процессов.

Сертифицируемая инфраструктура должна быть отделена от других сетей организации — доступ к ней обязан предоставляться через изолированный интерфейс. Чтобы выполнить это требование, мы используем VPN с 2FA и изолируем сегмент каждого клиента.

Внутри периметра располагается NTP-сервер, сервисы логирования, антивирус, файрвол, а также решения для предотвращения кибератак и контроля сохранности данных. Схему нашей сети можно посмотреть здесь.

Этап 3: прохождение пентеста

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

Перед тем как начать проверку инфраструктуры на устойчивость к проникновению, наша команда подготовила два скопа. Первый со служебными сервисами и приложениями, участвующими в тестировании. На второй была настроена ВМ с ОС, назначены необходимые права соответствующим учетным записям.

/ Пример скопа с размещенными сервисами и приложениями

Пентест нашей инфраструктуры проводился в несколько этапов.

Сканирование утилитой nmap

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

Подключение по VPN и проверка внутренней сети

Пентест-команда попыталась получить доступ из недоверенной сети. Результаты теста показали, что проникнуть в инфраструктуру «ИТ-ГРАД» по VPN без 2FA нельзя. Проверка внутренней сети также не выявила нарушений.

Попытка доступа подключения к инфраструктуре по учетной записи

На стороннем ресурсе (этим ресурсом был iaas-blog.it-grad.ru) эксперты получили учетные данные одного из наших коллег. Этот коллега также имел учетку в тестируемой инфраструктуре «ИТ-ГРАД». Аудиторы попытались авторизоваться, используя его аккаунт и пароль, но у них это не получилось, так как сеть была достаточно сегментирована.

Всего по итогам проверки у нас обнаружили 7 уязвимостей разной степени критичности: одну высокого и по 3 среднего и низкого уровня «опасности».

Наша самая критичная уязвимость — неправильная работа WAF — возникла из-за того, что используемый межсетевой экран не справлялся со сложными атаками. Для того чтобы устранить уязвимость мы развернули веб-сервер Apache с модулем Modsecurity, а затем обновили БД сигнатур WAF.

Уязвимостей среднего уровня было три. Первая — включенный метод TRACE, который злоумышленники могут использовать, например, для межсайтового скриптинга. Чтобы устранить уязвимость, мы деактивировали метод TRACE.

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

И третья уязвимость — незащищенность программного обеспечения на одном из хостов (из-за устаревшей версии ПО). Для устранения этой уязвимости мы настроили регулярные обновления ПО на всех узлах.

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

Этап 4: финальный аудит

На последнем этапе проверки аудитор оценивает комплектность и параметры ПО и железа, топологию сети, конфигурацию ОС, изолированность сегментов инфраструктуры и другие характеристики. Кроме того, он может проверить документацию и знания сотрудников, задать вопросы организационного или технического характера.

Если у вашей компании обнаружатся незначительные отклонения от требований стандарта, их можно устранить во время аудита. Например, у нас нашли неактивную учетную запись компьютера в Active Directory, которую мы оперативно удалили.

Если вам потребовалось что-то поменять до или во время аудита, это тоже не проблема. Главное здесь — вносить изменения так, как этого требует PCI DSS.

Например, перед аудитом нам в «ИТ-ГРАД» понадобилось отследить загрузку и выгрузку файлов на SFTP-сервере. Для этого мы должны были срочно написать декодер для сервера avusm. Без декодера сервер не сохранял нужные сообщения, поскольку не мог «разбирать» логи и формировать оповещения.

В конечном счете мы получили сертификат соответствия требованиям PCI DSS и стали одним из первых IaaS-провайдеров в России, который оказывает услугу хостинга PCI DSS.

Источник

PCI DSS: что это такое и как под него сертифицироваться + наш опыт

— Хорошо, теперь покажите ваш статический анализатор кода.
— Знакомьтесь, это Пётр.
— Приятно познакомиться, но…
— Пётр и есть наш статический анализатор кода.

Когда вы работаете с платёжными данными, то должны обеспечивать определённый уровень безопасности. Этот уровень описан в стандарте PCI DSS, разработанном Visa, MasterСard и другими платёжными системами. Он важен, поскольку применяется ко всем участникам процесса работы с данными держателей карт, но есть дополнительные требования для поставщиков услуг.

В стандарте 12 разделов — начиная от того, что служба безопасности должна следить за сменой доступов и изъятием пропусков после увольнения сотрудников, и заканчивая тем, как и куда должны писаться всевозможные логи.

Расскажу, как мы сертифицировали нашу облачную платформу и сколько нервов это вымотало.

Проблема коротко

Изначально у каждой платёжной системы — Visa, MasterCard, American Express, JCB и Discover — имелись свои программы с минимальным набором требований по безопасности при работе с данными держателей карт, и эти требования пересекались. Затем был сформирован Совет Payment Card Industry Security Standards Council (PCI SSC), в который вошли платёжные системы, указанные раньше. В 2004 году была выпущена первая версия PCI DSS 1.0. В ней были описаны минимальные требования ко всем участникам процесса хранения, обработки и передачи данных держателей карт.

Где-то во второй половине 2000-х стали активно развиваться облачные вычисления. Выяснилось, что некоторые нюансы облаков как относительно нового типа хостинга не учитываются в текущей версии стандарта PCI DSS. Например, не учитывается архитектура, в которой идёт постоянное изменение набора компонентов и их количества, а также реализация некоторых технических решений. Часть требований может быть неприменима из-за отсутствия различных процессов. Например, требования раздела 4 про шифрование платёжных данных при передаче через сети общего пользования. В нашем случае данная задача ложится полностью на клиента. По большей части одни и те же требования применяются как к площадке хостинга, так и к виртуальной инфраструктуре клиента.

В целом все пункты очень здравые и на первый взгляд понятные. Вот прямо взять и сделать. Но когда начинаешь делать — начинаются сложности и толкования. Например, в требованиях стандарта есть пункт о необходимости статического анализа кода. У нас большая часть кода написана на языке Python, в настоящий момент статических анализаторов кода нет — точнее, есть, например, Bandit, но конкретно к нашей истории он не подходил. Поэтому выполнять анализ кода на безопасность стал человек Пётр. Именно его мы сдавали как статический анализатор. Человек Пётр требованиям к анализатору соответствовал. Примерно в том же ключе шли некоторые другие пункты.

Зачем сертифицировать облако

Наши заказчики используют облако для решения своих задач. Например, решили добавить какой-то сервис в банке, а потом через полгода выяснилось, что он в продакшине жрёт слишком много ресурсов, и надо дозакупать железо. Железо едет долго, оно дорогое, согласования мучительные. Естественно, с облаком в разы удобнее — да и все уже давно привыкают платить за ресурсы по мере потребления и быстро масштабироваться.

Но просто так взять и встать в облако нельзя — площадка облачного провайдера (то есть в данном случае наша), на которой заказчики хранят, обрабатывают и передают данные держателей карт платёжных систем Visa и MasterСard, должна соответствовать стандарту PCI DSS. Иначе с ним нельзя работать. Если клиент не работает с такими данными, то сертификация ему не нужна.

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

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

Как шёл аудит

Мы готовились к аудиту больше года.

Вся платформа облака построена нами с нуля и изначально не учитывала требования PCI DSS. Да, в основе лежит технология KVM — это красношапочники, но это далеко не единственный компонент облака. Нашим разработчикам пришлось написать тонну кода и допиливать напильником уже существующие технологии, чтобы всё работало как надо.

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

По всем сложным моментам история такая: есть требования. Не важно, как устроена система, главное, чтобы требования выполнялись. Если непонятно толкование и как приземлять его на свою инфраструктуру — можно попросить аудитора оценить, подходит решение или нет. Зачастую при этом приходилось вступать в дискуссию, доказывая специфику платформы и правильность выбранного решения, которое не всегда очевидно. Обязательным требованием сертификации является ежегодное прохождение пентеста. Для себя мы выбрали несколько моделей нарушителей: внешний злоумышленник, скомпрометированный сотрудник (он же зловредный сотрудник) или клиент.

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

Вот, например, нужно вести учёт всех системных компонентов документированно. Сюда входит всё, что относится к платформе: сетевое оборудование, средства мониторинга, все инфраструктурные серверы, средства защиты и т. д. Для каждого компонента требуется указать его расположение, версию ПО, IP-адрес. Когда у тебя таких компонентов 50 — проблем нет, но что делать, если их 500? Вдобавок количество компонентов постоянно меняется — и не только в разрезе числа серверов, но и по ролям на каждом сервере. Всё облако построено на ролях, может добавиться сервер с ролью, может добавиться роль к серверу. И всё это многообразие постоянно движется, причём, как правило, в большую сторону. Понятное дело, что ручным трудом тут не обойдёшься, пока будешь составлять актуальный список, он уже изменится, возможно, несколько раз. Пришлось внедрять самописную автоматизацию — систему сбора данных по облаку, чтобы в любой момент времени получить подробный отчёт о всех компонентах. Такая же была проблема с сетевыми схемами. Стандарт требует отображения всех компонентов на уровне L2-L3-модели модели OSI. Их также больше 500, и их тяжело отобразить на одной схеме. А главное, схема будет совсем нечитаемой. Искали варианты, как сгруппировать, чтобы просто это можно было охватить взглядом. Схему сделать надо, а это сложно (и порой кажется почти нереализуемым). Тоже нашли выход.

Есть проблемы мониторинга — расширенные журналы регистрации событий и система контроля целостности на всех компонентах.

Согласно требованиям стандарта, нужно вести логирование действий всех пользователей, а также собирать все логи критичных компонентов на внешнем сервере и анализировать их. Первая часть задачи не выглядит страшной, даже с учётом большого числа компонентов, т. к. умеем управлять такой большой инфраструктурой. Но вот с анализом возникают трудности. Логи прилетают в огромном количестве, если просматривать вручную, то на это уйдут недели. Может, даже месяцы. Для решения этой задачи внедряли специальный механизм сбора и анализа логов, который позволил мониторить логи в режиме реального времени и выдавать алармы в случае срабатывания тригерров. Естественно, с тригеррами пришлось попотеть…

Вторая проблема — механизм контроля целостности. Для начала нужно было определить список критичных конфигураций и логов, за которыми нужно следить, создать под них шаблоны и разлить согласно ролям. В принципе задача достаточно тривиальная — за одним но… Из-за объёма триггер может сработать на автоматизированный процесс. Поначалу мы получали тонны писем о срабатывании системы контроля со всех компонентов. Ушло немало трудочасов, чтобы всё настроить.

Перед проведением внутреннего сканирования в первый раз надо очень аккуратно настроить профили сканирования и прогнать их на тестинге по многу раз, чтобы выявить любые отклонения от нормальной работы сервисов. Расчётная часть была довольно интересная. То же касается и тестирования на проникновение — нужно обговорить все детали, прежде чем начнут ломать прод. Во время теста пришлось пристально смотреть на системы мониторинга, чтобы заметить любые отклонения.

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

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

В итоге в проекте было поставлено 478 Jira-тикетов, потребовался 1 год. Аудитора мы постоянно дёргали вопросами, он отвечал, толковал и делился мировым опытом. Результат — сертификат на облачную платформу на базе KVM. И сразу несколько заказчиков, которые хотят обрабатывать свои платёжные данные там.

Как и с другими аудитами, от этого — если его делать с полной отдачей — выигрывает и компания в целом, поскольку он затрагивает процессы организации и ещё много чего, и там лучшие мировые практики по безопасности. Да, нескольким подразделениям добавилось работы, нужно соблюдать все процессы для ежегодного поддержания статуса PCI DSS. Но в целом стало лучше.

Источник