Защита от утечки данных Azure SQL из корпоративной сети

Question

У меня вопрос по DLP (предотвращение утечки данных) из корпоративной сети.

У меня есть виртуальная машина в корпоративной сети. Виртуальная машина может обращаться к базе данных SQL Azure в облаке: aaa.database.windows.net через соединение через порт 1433.

Однако я не хочу, чтобы эта же виртуальная машина подключалась к bbb.database.windows.net.

Azure не предоставляет никаких гарантий для общедоступного IP-адреса (оба сервера могут отображаться как один и тот же IP-адрес) - какую технологию я могу использовать в корпоративной периметровой сети / брандмауэре, чтобы разрешить доступ к AAA, но запретить доступ к BBB?

Атака, которой я обеспокоен, - это кто-то внутри компании, запрашивающий данные у ааа и вставляющий их в bbb. Например, если один сервер - ourcorporatedate.database.windows.net, а другой - somerandom.database.windows.net, то кто-то внутри компании может взять корпоративные данные и записать их в произвольную базу данных.

Спасибо

Answer 1

Если базы данных aaa и bbb имеют одинаковый публичный IP-адрес. Я думаю, что в локальном брандмауэре нет хорошего способа разрешить доступ к AAA, но запретить доступ к BBB. От того же клиента правило брандмауэра будет иметь тот же IP-адрес источника, протокола, порта и IP-адреса назначения для исходящего трафика.

Если вы хотите выборочно предоставить доступ только к одной из баз данных на SQL-сервере Azure, вы можете создать правило уровня базы данных только для требуемой базы данных. Кроме того, укажите диапазон IP-адресов для правила брандмауэра базы данных, выходящий за пределы диапазона IP-адресов, указанного в правиле брандмауэра на уровне сервера, и убедитесь, что IP-адрес клиента попадает в диапазон, указанный в правиле уровня базы данных. Правила уровня сервера разрешают доступ к Azure SQL Server. Это означает, что клиент будет иметь доступ ко всем базам данных, хранящимся на этом SQL Server. Обратитесь к этому документ .

Answer 2

Текущая функция VPN в SQL Azure напрямую не предотвращает это (но, пожалуйста, поищите будущие обновления, где это запланировано для функции конечных точек службы для SQL Azure). Тем не менее, есть различные способы смягчения, которые вы можете использовать для обнаружения или уменьшения возможности сделать это:

1. Вы можете включить аудит в базе данных aaa. Это может обнаружить все логины и основные изменения состояния БД. (Detect)
2. Вы можете уменьшить разрешения для различных типов пользователей в базе данных до минимума и использовать функции, которые еще больше уменьшают размер данных, которые клиент может копировать из базы данных вообще. Это включает в себя безопасность на уровне строк, маскирование данных, всегда зашифрованное (которое вы могли бы заблокировать для конкретного приложения / пользователя, чтобы иметь возможность расшифровывать конфиденциальные данные в клиенте - другие клиенты без ключа просто получают кипертекст) и т. Д.
3. Используйте правила брандмауэра (как указано в других ответах), чтобы ограничить, какие клиенты могут подключаться к базе данных вообще - тогда вы можете ограничить, где они могут подключаться с разрешениями.

Обратите внимание, что логические серверы SQL Azure обычно не подразумевают, что каждая база данных клиентов на этом сервере имеет одинаковый IP-адрес. В настоящее время в конечных точках службы есть ручка (страница документации в данный момент недоступна, поэтому я не могу получить ссылку на нее) для настройки, проходите ли вы через шлюз для региона или нет. Если вы этого не сделаете (рекомендуется), вы увидите IP-адрес хост-узла, который со временем может измениться. Функция конечных точек службы предоставит пользователям VPN больший контроль над правилами сетевого уровня, но некоторые из этих функций еще не запущены в производство. Я призываю вас смягчить с помощью других шагов (выше), пока это не доступно для вас.

Answer 3

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