Microsoft Azure — идентификация и доступ к управлению для Azure SQL

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

Все операции Azure, которые вы выполняете для развертывания различных ресурсов, используют RBAC. Это система, основанная на определенных разрешениях от подписок, людей, у которых есть подписки на основе различных ролей. Например, у вас есть владелец подписки или что-то, называемое участником, который имеет доступ и может дать разрешение на развертывание ресурсов Azure, таких как Azure SQL.

Azure RBAC отделен от системы безопасности SQL, которой вы бы предоставили права аутентификации для входа в SQL Server, но он предоставит вам все эти права и доступ для контроля и управления ресурсами Azure. Разделение обязанностей от развертывания ресурсов Azure и управления ими до самой системы безопасности SQL Server. Вы можете использовать портал Azure или интерфейс командной строки для прохождения и использования политик и систем типа RBAC.

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

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

Самое первое, о чем вам нужно подумать, это аутентификация в смешанном режиме. В SQL Server у вас есть два типа режимов:

1. Аутентификация Windows или встроенная безопасность
2. SQL-аутентификация.

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

Теперь вы говорите себе: «Это интересно, но мне нужна проверка подлинности Windows, мне нужна встроенная проверка подлинности безопасности», и поэтому Azure предоставляет и позволяет выполнять проверку подлинности Azure Active Directory для администраторов и для входа в систему. Вот как это выглядит для управляемого экземпляра.

Управляемый экземпляр Azure:

• Администратор сервера Azure AD
• Логины SQL или Azure AD
• Пользователи базы данных
• Поддержка автономных баз данных SQL Server

Для управляемого экземпляра добавляется логин SQL, который является системным администратором, вы также можете создать администратора Azure Active Directory Server, и он становится членом роли системного администратора. Кроме того, вы можете создавать учетные записи так же, как вы привыкли сегодня, с помощью SQL Server для входа SQL или входа Azure Active Directory, как и для входа Windows. Затем вы можете пройти процесс создания пользователей базы данных, сопоставленных с этими логинами. Azure даже поддерживает эту концепцию, как в SQL Server, системы автономной базы данных SQL Server.

База данных SQL Azure:

• Администратор сервера Azure AD
• Логины SQL
• роли loginmanager и dbmanager для ограниченных администраторов сервера
• Пользователи базы данных
• Пользователь автономной базы данных, включая Azure AD

Очень похоже на MI, вы можете создать администратора сервера Azure Active Directory, который будет таким же, как тот администратор SQL, который вы создали в начале при развертывании базы данных SQL Azure. Вы также можете создавать логины SQL, но здесь есть небольшое расхождение. У нас есть специальные роли администратора сервера на логическом сервере, которые позволят определенным логинам управлять логинами или базами данных на вашем логическом сервере. Теперь вы можете создавать пользователей базы данных, сопоставленных с этими логинами, а также в базе данных Azure, но вот что рекомендует Azure; В Azure есть концепция пользователей автономной базы данных без создания автономной базы данных, и они могут даже быть пользователями Azure Active Directory.

Теперь, когда вы увидели, как выглядят возможности для аутентификации, важно помнить, что при развертывании вы выберете администратора SQL Server. Но после развертывания вы можете добавить администратора Azure Active Directory как для MI, так и для базы данных Azure. Затем, как и в случае с SQL Server, администраторы, прошедшие проверку подлинности, теперь могут создавать других пользователей, другие логины. Затем, когда вы закончите этот процесс, вы предоставите доступ к SQL Server в этой системе точно так же, как и к SQL Server, независимо от того, использует ли он роли, предоставляет ли это определенную аутентификацию объектам, входам или пользователям.

Вам нужен Azure RBAC, чтобы получить права на работу с Azure. После того, как вы получите эти ресурсы и развернете их, вы будете использовать методы проверки подлинности SQL Server, которые в некоторых случаях немного отличаются от MI и базы данных, включая проверку подлинности Azure Active Directory. Тогда это будет похоже на SQL Server. Он предоставит этот доступ к нужным вам объектам на основе ролей, или на основе созданных вами логинов, или на основе пользователей базы данных.