Как встроить безопасность в качестве функции SaaS: руководство

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

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

Вам нужно начать думать о безопасности как о функции. Если вы вице-президент по разработке, если вы менеджер по продукту, владелец продукта, уделите время безопасности, позвольте вашим разработчикам создать лучшую и более безопасную инфраструктуру.

— Джоэл Спольски , основатель Stack Overflow

Самыми успешными продуктами в ближайшее десятилетие будут те, которые осознают, что подходы статус-кво больше не являются достаточно хорошими. Вам также не нужно верить Джоэлу на слово; ознакомьтесь с подробностями недавно анонсированной технологии Private Cloud Compute от Apple. Одна из самых успешных компаний за последние два десятилетия четко заявляет, что безопасность, конфиденциальность и доверие будут основными отличительными чертами.

Они даже обсуждают, что нынешнее использование таких протоколов, как TLS, не может обеспечить сквозные гарантии безопасности и конфиденциальности, на которые могут рассчитывать клиенты.

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

В то время соединение двух отдельных сетей имело очевидную и физически осязаемую реальность.

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

Тем не менее, мы продолжаем использовать старые подходы как способ «безопасного» соединения наших систем.

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

Необходимость подключения к частной системе

То, что люди имеют в виду, когда говорят «облако» или «локально», за последние десятилетия стало размытым. Чтобы избежать путаницы, я создам для нас гипотетический сценарий:

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

• ACME Corp: Это крупный клиент Initech, которого вы хотите поддержать. Они управляют большой инфраструктурой в разных местах. Это «локально» в классическом смысле — внутри собственного центра обработки данных? Это внутри собственного VPC одного из крупнейших облачных провайдеров? Это не имеет значения! Системы клиентов работают в одной или нескольких сетях, которые Initech не контролирует, к которым у нас нет доступа и к которым нет прямого доступа из общедоступного Интернета.

Проактивное участие в рабочих процессах разработчиков

При создании ранней версии платформы Initech необходимо работать с множеством потенциальных клиентов, чтобы доказать соответствие продукта рынку. Он будет интегрироваться с общедоступными API основных поставщиков систем контроля версий (например, GitHub, GitLab, Bitbucket и т. д.), использовать коммиты/веб-хуки для реагирования на события, отправлять результаты в рабочий процесс, и все будет работать как положено.

Это здорово, поскольку продукт пассивен и просто реагирует на события, инициированные кем-то из ACME Corp. Многие сервисы хотят приносить пользу, оценивая внешние изменения в мире и активно внося улучшения для своих клиентов.

Подумайте о многочисленных службах сканирования зависимостей или безопасности: если обнаруживается новая уязвимость, они хотят как можно быстрее создать запрос на извлечение/слияние во всех затронутых репозиториях. Полностью управляемые службы VCS с общедоступными API предоставляют возможность реализовать это, однако локальные версии этих продуктов не имеют общедоступного API.

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

Доступ к личным данным

Initech необходимо запросить базу данных, чтобы отобразить свое собственное решение для создания отчетов. Это не проблема, присущая Initech, поскольку почти каждая платформа данных клиентов (CDP) или инструмент визуализации сталкивается с одной и той же проблемой: клиенты не хотят делать свои личные данные доступными из общедоступного Интернета, поэтому они обычно находятся в база данных в частной подсети.

Проблемы наших нынешних подходов

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

Вместо этого они пытаются внести минимальные изменения в то, как все работало раньше, чтобы приблизиться к тому, как нам нужно, чтобы все работало сегодня.

Размещение систем в общедоступном Интернете

Вариантом развертывания по умолчанию для большинства частных систем является размещение их в частной сети с частной подсетью без общедоступных IP-адресов. Для этого есть очень веские причины! Самый простой вариант для Initech подключиться к этой частной системе — попросить ACME Corp предоставить публичный IP-адрес или имя хоста, к которым можно будет получить доступ из Интернета.

Это плохо.

Все веские причины для первоначального помещения системы в частную сеть, отключенную от мира, немедленно исчезают. Эта система теперь доступна всему общедоступному Интернету, что позволяет тысячам потенциальных хакеров постоянно пытаться взломать систему или просто выполнить DoS-атак. Вы находитесь в одном шаге от утечки учетных данных, CVE или другой проблемы, чтобы стать владельцем.

Обратные прокси

Другой подход — установить обратный прокси-сервер перед системой. Я говорю не только о чем-то вроде nginx и HA Proxy; существует целая категория размещенных или управляемых сервисов, которые также подходят под это описание.

Преимущество этого заключается в том, что корпорация ACME больше не размещает частную систему непосредственно в общедоступном Интернете. Обратный прокси-сервер также добавляет возможность ограничения скорости или точной настройки ограничений доступа для смягчения потенциальных DoS-атак. Это улучшение глубокоэшелонированной защиты, но ACME Corp по-прежнему позволяет всему общедоступному Интернету подключаться к прокси-серверу и пытаться атаковать его.

Если он скомпрометирован, он будет делать то же, что и прокси-сервер: пропускать трафик по назначению.

Списки разрешенных IP-адресов

Постепенным улучшением является то, что Initech предоставит список IP-адресов, с которых они будут отправлять запросы, и позволит ACME Corp управлять своим брандмауэром и правилами маршрутизации, чтобы разрешать запросы только с этих IP-адресов. Хотя это не такое уж большое улучшение.

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

Таким образом, IP-адреса, скорее всего, будут принадлежать шлюзу NAT или прокси-серверу. Корпорация ACME может предположить, что блокировка доступа только к одному или двум исходным IP-адресам означает, что только одна или две удаленные машины будут иметь доступ к своей сети.

Реальность такова, что все в удаленной сети, которое может отправлять запросы через шлюз или прокси-сервер NAT, теперь также получит доступ к сети ACME Corp. Это не позволяет использовать ни одно приложение или компьютер; вы разрешили всю удаленную сеть.

Еще более тревожным является то, что исходные IP-адреса тривиально подделываются . Потенциальный злоумышленник сможет создать правильно сформированный запрос, подделать адрес источника и отправить данные или инструкции в сеть ACME Corp. Поставщики SaaS, включая Initech, также неизбежно должны документировать список текущих IP-адресов, чтобы иметь готовый список IP-адресов, которые можно попытаться выдать за другое лицо.

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

Подумайте о системах, которые мы подключаем: насколько вы уверены в том, что не существует вызовов API по принципу «выстрелил и забыл», которые не будут корректно создавать, обновлять или уничтожать ценные данные? Хорошая безопасность — это больше, чем просто предотвращение раскрытия данных, это также их защита и гарантия их целостности.

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

Виртуальные частные сети (VPN)

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

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

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

Если бы я попросил вас сделать физическую версию этого, подключить кабель из вашей производственной среды непосредственно к производственной среде другой компании, вы, вероятно, немного приостановились бы. Много пауз. И не зря. Но VPN являются «виртуальными», «частными», настолько простыми (по сравнению с прокладкой кабеля) и настолько повсеместными, что мы не придаем этому особого значения.

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

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

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

Вы не можете доверять сети

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

отраслевые данные показывают, что менее 1% крупнейших предприятий мира еще не предприняли никаких шагов для защиты своей сети от этой новой и возникающей угрозы…

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

— Митчелл Джонсон , Sonatype

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

Посмотрите, как это может выглядеть с точки зрения корпорации ACME:

Теперь это не просто две сети и две компании, связанные друг с другом; это много сетей. У каждого поставщика SaaS будет свой собственный набор используемых сервисов, что еще больше умножает это преимущество. Вы не можете доверять не только сети, но и никому другому. Любой участник этой картины — это всего лишь неправильная конфигурация сети или скомпрометированная зависимость, не позволяющая передать риск через сеть(и).

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

Итак, давайте решим это!

Мы можем встроить безопасность в наш продукт за считанные минуты! Мы поднимем планку безопасности, предоставив более целенаправленное и детализированное решение. Мы также собираемся перестать перекладывать проблемы на таких клиентов, как ACME Corp, прося их внести изменения на уровне сети.

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

В приведенном здесь примере будет показано, как платформа Initech может установить соединение с автономным сервером GitHub Enterprise, которым управляет корпорация ACME. Конечный результат будет выглядеть так:

Чтобы раскрутить все необходимые детали, потребуется всего несколько минут! Чтобы узнать, как это сделать, ознакомьтесь с нашим обзором кода для создания основы автономного агента .