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

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

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

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

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

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

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