За последние несколько лет концепция архитектуры «нулевого доверия» прошла ряд этапов эволюции. Из новой модной причуды она превратилась в банальность (в значительной степени из-за потока маркетинга со стороны тех, кто хочет нажиться на этой тенденции), прошла, и теперь в конечном итоге превратилась в то, чем, вероятно, всегда должно было быть. вместе: надежный, практичный вариант безопасности с дискретными, наблюдаемыми преимуществами и недостатками, который может быть включен в подход нашей организации к обеспечению безопасности.
Нулевое доверие, как следует из названия, представляет собой модель безопасности, в которой все активы — даже управляемые конечные точки, которые вы предоставляете, и локальные сети, настроенные вами, — считаются враждебными, ненадежными и потенциально уже скомпрометированы злоумышленниками. Вместо устаревших моделей безопасности, которые отличают «доверенный» внутренний от ненадежного внешнего, нулевое доверие предполагает, что все сети и хосты одинаково ненадежны.
После того, как вы сделаете этот фундаментальный сдвиг в предположениях, вы начнете принимать разные решения о том, чему, кому и когда доверять, и разрешены допустимые методы проверки для подтверждения запроса или транзакции.
С точки зрения безопасности это имеет свои преимущества и недостатки.
Одним из преимуществ является то, что он позволяет вам стратегически применять ресурсы безопасности там, где они вам нужны больше всего; и это увеличивает сопротивление атакующему боковому движению (поскольку каждый ресурс нужно ломать заново, если они установят плацдарм).
Есть и недостатки. Например, принудительное применение политик требуется для каждой системы и приложения, и более старые устаревшие компоненты, созданные с различными предположениями безопасности, могут не подходить хорошо, например что внутренняя сеть заслуживает доверия.
Один из наиболее потенциально проблемных недостатков связан с проверкой состояния безопасности, то есть в ситуациях, когда модель безопасности требует проверки более старыми, более ориентированными на наследие организациями. Эта динамика неудачна: те же организации, которые, вероятно, сочтут модель наиболее убедительной, — это те же организации, которые, приняв ее, скорее всего, решат проблемы проверки.
Проверка и минимизация воздействия
Чтобы понять динамику, которую мы здесь имеем в виду, полезно подумать, какой следующий логический шаг будет после принятия нулевого доверия. В частности, если вы предполагаете, что все конечные точки потенциально скомпрометированы, а все сети, вероятно, являются враждебными, естественным и логическим следствием этого предположения является минимизация того, куда могут попасть конфиденциальные данные.
Вы можете, например, решить, что определенные среды недостаточно защищены для хранения, обработки или передачи конфиденциальных данных, кроме как через очень узко определенные каналы, такие как аутентифицированный HTTPS-доступ к веб-приложению.
В случае интенсивного использования облачных сервисов вполне логично решить, что конфиденциальные данные могут храниться в облаке — при условии, конечно, механизмов контроля доступа, которые созданы специально для этой цели и имеют безопасность. меры и оперативный персонал, которые вы не можете себе позволить развернуть или содержать только для собственных нужд.
В качестве примера предположим, что у вас есть гипотетическая более молодая организация на среднем рынке. Под словом «моложе» мы подразумеваем, что с момента создания организации прошло всего несколько лет. Скажем, эта организация является «родной для облака», то есть на 100% экстернализована для всех бизнес-приложений и построена полностью на использовании облака.
Для такой организации отсутствие доверия является обязательным условием. Поскольку он на 100% экстернализован, у него нет центров обработки данных или внутренних серверов, и он поддерживает только самые минимальные локальные технологии. Эта организация может прямо потребовать, чтобы никакие конфиденциальные данные не могли «жить» на конечных точках или внутри их офисной сети. Вместо этого все такие данные должны находиться в подмножестве известных, определенных облачных сервисов, которые явно одобрены для этой цели.
Это означает, что организация может сосредоточить все свои ресурсы на укреплении облачной инфраструктуры, службах шлюза, чтобы весь доступ (независимо от источника) был надежно защищен, и лишить приоритета такие вещи, как физическая безопасность, укрепление внутренней сети (при условии, что она вообще существует), развертывание средств внутреннего контроля и т. д. Если для обеспечения безопасности использования облачных компонентов соблюдается тщательный и производительный процесс, такой подход может помочь сосредоточиться на ограниченных ресурсах.
Однако приведенный выше пример организации не работает в вакууме — ни одна организация не работает. Он работает с клиентами, руководит процессом продаж, деловыми партнерами и многими другими. Поскольку организация меньше, многие из ее клиентов могут быть крупными организациями — потенциально клиентами с жесткими требованиями к защите внешних поставщиков услуг и проверке их безопасности. Возможно, у него есть нормативное обязательство делать это в зависимости от отрасли, в которой он работает. Теперь некоторые из этих клиентов могут быть полностью экстернализованы, но большинство не будет — у них будут устаревшие приложения, уникальные ограничения, специализированные требования и другие бизнесы. причины, по которым они не могут поддерживать полностью внешнюю модель.
Какие результаты часто являются вполне понятными, но, тем не менее, контрпродуктивными, дискуссиями о перекрестных целях между организацией, проводящей оценку (потенциальный клиент), и той, которая оценивается (поставщик услуг). Поставщик услуг, например, может очень разумно утверждать, что меры контроля физической безопасности (если выбрать только один пример) выходят за рамки целей оценки. Они могут утверждать это на том основании, что единственные меры физической безопасности, которые имеют значение, — это те, которые применяются у облачных провайдеров, поскольку, в конце концов, это единственное место, где разрешено хранить данные.
Заказчик, с другой стороны, также может разумно беспокоиться об аспектах физической безопасности, которые действительно связаны со средой поставщика услуг. Например, доступ посетителей к объектам, где данные клиентов можно просматривать на экране, даже если данные там не хранятся. Они могут представить себе сценарий, например, когда неавторизованный посетитель в офисе может «просматривать» данные, когда они вводятся на экран легитимным пользователем.
Разговор, подобный приведенному выше, даже если он не вызывает споров, все же неоптимален для обеих сторон. С точки зрения поставщика услуг, это замедляет процесс продаж и отнимает время у инженеров, которые в противном случае были бы сосредоточены на разработке продукта. Однако с точки зрения потенциального клиента это заставляет их нервничать по поводу потенциальных источников неучтенного риска — одновременно вызывая недовольство у внутренних деловых партнеров, стремящихся использовать услугу и желающих, чтобы проверка прошла быстро.
Основные стратегии
Таким образом, возникает вопрос: как мы можем эффективно сообщить о модели нулевого доверия, если мы хотим использовать ее таким образом? Если мы подтверждаем такой подход, как нам ответить на правильные вопросы, чтобы мы могли быстро прийти к определению и (в идеале) разрешить бизнес-использование сервиса? Оказывается, мы можем использовать несколько подходов. Ни один из них не занимается ракетостроением, но для поддержки им требуется сопереживание — и некоторая беготня.
С точки зрения поставщика услуг, следует помнить о трех полезных принципах: 1) быть готовым, 2) демонстрировать подтверждение ваших предположений и 3) подтверждать свои утверждения документацией.
Под «готовностью» я подразумеваю готовность поделиться информацией, выходящей за рамки того, о чем мог бы спросить покупатель. Если вы предоставляете облачное SaaS, как в приведенном выше примере, это может означать, что вы готовы делиться информацией, выходящей за рамки определенного набора элементов, запрошенных клиентом. Это позволяет вам «обобщать» информацию даже с точки зрения использования стандартных результатов. Например, вы можете рассмотреть возможность участия в реестре CSA STAR, подготовить стандартные артефакты для сбора информации, такие как CSA CAIQ, SIG для стандартизированной контрольной оценки общих оценок или HITRUST Third Party Assessment Program в сфере здравоохранения.
Второй принцип, демонстрирующий валидацию, означает, что вы подтвердили предположения, которые вошли в вашу модель безопасности. В приведенном выше примере это означает, что мы могли бы подтвердить предположение о том, что «данные не хранятся внутри», проверив его. Оценщик от заказчика с гораздо большей вероятностью поверит этому утверждению, если для его проверки используется такой контроль, как DLP.
Последний пункт наличия документации означает документирование модели, которую вы поддерживаете. Например, если вы можете предоставить архитектурный документ, описывающий ваш подход: почему вы его применяете, анализ рисков, который вы выполнили заранее, средства контроля для проверки и т. Д. Подкрепите его определенной политикой, которая устанавливает принципы и ожидания безопасности .
Со стороны оценщика на самом деле существует только один принцип: проявлять гибкость там, где это возможно. Если вы понимаете намерение и строгость средств управления, которых вы ожидаете, и поставщик услуг выполняет то же намерение с тем же уровнем строгости, но другим способом, чем вы ожидаете, предоставляя поставщику услуг варианты (кроме требования приобретать и устанавливать элементы управления, которые им не нужны).
Опять же, конечно, ни один из этих советов не относится к ракетостроению. Но то, что это очевидно, не означает, что все это делают. Сделав некоторую работу заранее и посмотрев сквозь призму эмпатии, вы можете упростить процесс оценки в такой ситуации. 
