Комментарии 12
Можно ли использовать Docker как вирутуальную машину? Имеется ввиду там есть требование по изоляции приложений. Docker для этого подходит?
Обязательно ли поднимать локальные репозитарии с используемыми пакетами? А то ведь это куча сил на поддержку этого.
Обязательно ли поднимать локальные репозитарии с используемыми пакетами? А то ведь это куча сил на поддержку этого.
Обязательно ли поднимать локальные репозитарии с используемыми пакетами? А то ведь это куча сил на поддержку этого.
Да, обязательно, иначе теряется автономность. Если речь идет о пакетах с ПО — то представьте ситуацию: сгорел сервер, надо ставить новый. Или, если речь идет о пакетах с библиотеками — нашли уязвимость в проекте, который последний раз 5 лет назад дорабатывался, надо срочно исправлять. А центральный репозиторий не доступен — забыли продлить домен и его захватил киберсквоттер...
Да, для изоляции Docker использовать можно. Единственное, его нужно настроить в соответствии с требованиями PCI DSS (отключение небезопасных протоколов, ограничение доступа, удаление избыточного функционала и т.д.).
По поводу локальных репозиториев — поднимать их не обязательно, можно использовать публичные. Главное — не забывать вовремя обновлять пакеты.
По поводу локальных репозиториев — поднимать их не обязательно, можно использовать публичные. Главное — не забывать вовремя обновлять пакеты.
Я бы не стал так категорично заявлять. Правильный ответ, на мой взгляд: «На усмотрение аудитора в каждом конкретном случае».
Изоляции уровня аппаратного гипервизора контейнеризация не предоставляет: ядро системы одно на всех, уязвимость в нём — прямой путь из контейнера в контейнер. «Отключить [весь] лишний функционал», когда у вас есть доступ к ядру, пусть и с некоторыми навесными ограничениями, мне не кажется реально возможным. Аудитор в каждом конкретном случае решает — «адекватная» изоляция или нет. Причём, в следующем году другой аудитор может решить по-другому.
Также стандарты меняются, а кроме стандартов Совет PCI выпускает «информационные дополнения», которые могут приниматься во внимание аудиторами, а могут и игнорироваться. Например, году в 2013 году был выпущен документ, который практически не давал виртуально сегментировать облако, только физически, но его игнорировали сами аудиторы. В 2017 году вышло долгожданное руководство по сегментации, которое значительно облегчает решение задачи сегментирования, но, опять же, возлагает ответственность за проверку «адекватности» сегментирования на аудитора.
Изоляции уровня аппаратного гипервизора контейнеризация не предоставляет: ядро системы одно на всех, уязвимость в нём — прямой путь из контейнера в контейнер. «Отключить [весь] лишний функционал», когда у вас есть доступ к ядру, пусть и с некоторыми навесными ограничениями, мне не кажется реально возможным. Аудитор в каждом конкретном случае решает — «адекватная» изоляция или нет. Причём, в следующем году другой аудитор может решить по-другому.
Также стандарты меняются, а кроме стандартов Совет PCI выпускает «информационные дополнения», которые могут приниматься во внимание аудиторами, а могут и игнорироваться. Например, году в 2013 году был выпущен документ, который практически не давал виртуально сегментировать облако, только физически, но его игнорировали сами аудиторы. В 2017 году вышло долгожданное руководство по сегментации, которое значительно облегчает решение задачи сегментирования, но, опять же, возлагает ответственность за проверку «адекватности» сегментирования на аудитора.
Как понимаю, PCI DSS v3.2?
Пункты, которые становятся требованиями с января 2018 выполняли, или отложили на следующий раз?
Пункты, которые становятся требованиями с января 2018 выполняли, или отложили на следующий раз?
Например, в требованиях стандарта есть пункт о необходимости статического анализа кода.
Подскажите, пожалуйста, номер пункта с таким требованием?
Требования по анализу кода указаны в пунктах 6.3, 6.3.2 и 6.5
И где там хоть слово о статическом анализе?
В пунктах 6.3, 6.3.2 и 6.5 указаны требования по безопасной разработке кода с учетом мировых best practices. В свою очередь, best practices включает необходимость статического анализа кода на потенциальные уязвимости.
В таком случае, может быть вы удалите из статьи вышепроцитированный пассаж, ведь он не соответствует действительности?
Напишите корректно: «В требованиях стандарта есть пункт о необходимости учёта мировых best practices. Мы выбрали следующий(е) документ(ы) в качестве best practices [кстати, какие — читателям было бы полезно узнать] и в них содержится рекомендации использовать статический анализ, которые мы перефразировали в ..., против чего аудитор не возражал».
Да, пропадёт вся «искра» статьи, но зато не будет дезинформации.
Напишите корректно: «В требованиях стандарта есть пункт о необходимости учёта мировых best practices. Мы выбрали следующий(е) документ(ы) в качестве best practices [кстати, какие — читателям было бы полезно узнать] и в них содержится рекомендации использовать статический анализ, которые мы перефразировали в ..., против чего аудитор не возражал».
Да, пропадёт вся «искра» статьи, но зато не будет дезинформации.
это у вас еще, наверное, баз данных нет, в которых cardholder data… аудит транзакций — анализаторы логов «пухнут» от нагрузки :(
аудит аудита…
3 раза PCI DSS — ну его к монахам
аудит аудита…
3 раза PCI DSS — ну его к монахам
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
PCI DSS: что это такое и как под него сертифицироваться + наш опыт