Шинн отмечает: «Одна из проблем была в том, что аудиторы привыкли работать методами, не очень хорошо подходящими для шаблонов DevOps. Например, если аудитор видел среду с десятком тысяч серверов, он традиционно просил сделать выборку из тысячи серверов, вместе со скриншотами материалов по управлению активами, настроек контроля доступа, данных по установке агентов, логов серверов и так далее.
Для физических сред это нормально, — продолжает Шинн. — Но когда инфраструктура — это код, а из-за автомасштабирования серверы все время то появляются, то исчезают, как можно сделать выборку? Те же самые проблемы и с конвейером развертывания, он очень отличается от традиционного процесса разработки программного обеспечения, где одна группа пишет код, а другая вводит его в эксплуатацию».
Далее он объясняет: «В работе аудиторов самым распространенным методом сбора информации все еще остаются скриншоты и CSV-файлы, заполненные параметрами конфигураций и логами. Наша цель — создать альтернативные способы представления данных. Они четко показывают аудиторам, что наши средства контроля удобны и эффективны».
Чтобы сократить этот разрыв, у него есть команды, вместе с аудиторами разрабатывающие средства контроля. Они пользуются итеративным подходом, используя одно средство контроля за один подход, чтобы определить, что нужно для аудиторских доказательств. Благодаря этому аудиторы могут по запросу получать всю нужную им информацию, когда сервис находится в эксплуатации.
Шинн утверждает, что лучший способ добиться этого — «послать все данные в системы телеметрии, такие как Splunk или Kibana. Так аудиторы смогут получить все, что им нужно, без посторонней помощи. Им не требуется запрашивать выборку из данных, вместо этого они заходят в Kibana и ищут нужные аудиторские доказательства за конкретный временной период. В идеале они очень быстро найдут свидетельства того, что наши средства контроля действительно работают».
Шинн продолжает: «Благодаря современному аудиторскому логированию, чатам и конвейерам развертываний мы добились небывалой прозрачности и видимости того, что происходит в производственной среде, особенно если сравнивать с тем, как раньше обстояли дела в эксплуатации. Вероятность ошибок и брешей в безопасности стала гораздо меньше. Главная задача теперь состоит в том, чтобы преобразовать все эти доказательства в то, что аудитор сможет понять».
Для этого нужно, чтобы технические требования формировались на основе реальных нормативных требований. Шинн объясняет: «Чтобы найти, что требует HIPAA