Biztonsági képességek és tevékenységek
Az SQL Server és az Azure SQL-szolgáltatások közismert jellemzője, hogy nagy súlyt helyeznek a biztonságra, különösen amiatt, hogy nagyvállalati szintűek. Ebben a leckében megismerkedhet a hálózati biztonsággal és hozzáférés-kezeléssel kapcsolatos különböző biztonsági képességekkel. A következő egységekben gyakorlati tapasztalatokat szerezhet ezek közül a képességek közül.
Network security
A biztonság első rétege a hálózattal kapcsolatos. A hálózati képességek és a feladatok különböznek az Azure SQL Database és az Azure SQL Managed Instance között. A felügyelt Azure SQL-példányok hálózatkezelési képességeiről az Azure SQL Managed Instance Csatlakozás ivity architektúrája című témakörben olvashat.
Az Azure SQL Database hálózati biztonsága
Amikor az Azure SQL Database számára teszi biztonságossá a hálózatot négy fő lehetőség áll rendelkezésére:
- Hozzáférés engedélyezése Azure-szolgáltatások számára
- Tűzfalszabályok használata
- Virtuális hálózati szabályok használata
- Az Azure Private Link használata
Ezeken a fő lehetőségeken kívül lehetősége van az összes nyilvános hozzáférés letiltására (csak az Azure Private Link használatával), valamint egy minimális Transport Layer Security (TLS) verzió kényszerítésére. A legkevésbé biztonságos, de legegyszerűbben konfigurálható módszer az Azure-szolgáltatásokhoz való hozzáférés engedélyezése. A legbiztonságosabb módszer a Private Link használata. Az alábbi szakaszok az egyes lehetőségek által kínált képességeket, valamint az egyes lehetőségek konfigurálásának és karbantartásának módját ismertetik.
Hozzáférés engedélyezése Azure-szolgáltatások számára
Az Azure SQL Database üzembe helyezése során beállíthatja, hogy az Azure-szolgáltatások és -erőforrások hozzáférése igen értékre legyen állítva. Ha ezt a lehetőséget választja, akkor bármely erőforrásnak bármely régióból vagy előfizetésből lehetővé teszi az erőforrás elérését. Ezzel a beállítással az Azure SQL Database egyszerűen működésbe helyezhető, és csatlakoztatható olyan más szolgáltatásokhoz, mint az Azure Virtual Machines vagy az Azure App Service, vagy akár az Azure Cloud Shell, hiszen megengedi, hogy bármi csatlakozzon, ami az Azure-on keresztül érkezik.
Az Azure-szolgáltatások hozzáférésének engedélyezésével azonban nem engedélyezi, hogy az Azure-on kívül bármi (például a helyszíni környezet) hozzáférést kapjon.
A legbiztonságosabb konfiguráció az, hogy az Azure-szolgáltatások és -erőforrások hozzáférésének engedélyezése ehhez a kiszolgálóhoz nem értékre van állítva, amely letiltja az összes kapcsolatot és hálózatot, kivéve azokat, amelyeket kifejezetten hozzáadott a következő szakaszokban megjelenő különböző beállításokkal.
Firewall rules
A következő lehetőség a tűzfalszabályok alkalmazása. Az eredmények hasonlóak lehetnek az Azure-szolgáltatások és -erőforrások kiszolgálóhoz való hozzáférésének engedélyezéséhez, azzal a kivétellel, hogy minden egyes szolgáltatáshoz (a következő képen egy virtuális géphez)) hozzá kell adnia egy egyedi tűzfalszabályt a csatlakozás engedélyezéséhez. A tűzfalszabályok lehetővé teszik a helyszíni környezet számára az Azure SQL Database-erőforráshoz való csatlakozást is, mivel a helyszíni környezetben hozzáadhatja a gépekre és alkalmazásokra vonatkozó szabályokat.
Az Azure-beli kapcsolatokhoz Azure-szolgáltatások hozzáférését is engedélyezheti, majd felvehet tűzfalszabályokat külön a helyszíni kapcsolatokhoz. Ahogy korábban említettük, az Azure-szolgáltatások és -erőforrások hozzáférésének engedélyezése ehhez a kiszolgálóhoz nem olyan biztonságos, mert minden Azure-forgalmat lehetővé tesz. Javasoljuk, hogy kizárólag tűzfalszabályokat használjon.
Tekintsük meg az előző példát a konfigurált tűzfalszabályokkal. A Transact-SQL -t (T-SQL-t) támogató eszközről, például az SQL Server Management Studióból (SSMS) a következő lekérdezést futtathatja az Azure-beli virtuális gépről az SQLDBVNET-EUS virtuális hálózaton:
SELECT client_net_address FROM sys.dm_exec_connections WHERE session_id=@@SPID;
Az eredmény 174.17.218.16 lesz. Ez az Azure-beli virtuális gép nyilvános IP-címe. Annak ellenére, hogy tűzfalszabályokat használunk, minden kapcsolat nyilvános lesz.
Virtuális hálózati szabályok
Ha csak tűzfalszabályokat szeretne használni, a beállítás bonyolult lehet. Ha csak tűzfalszabályokat használ, az azt jelenti, hogy minden kapcsolathoz meg kell adnia egy IP-címtartományt, amely esetenként dinamikus IP-címekkel is rendelkezhet. Sokkal egyszerűbb alternatíva a virtuális hálózati szabályok használata az adatok eléréséhez szükséges virtuális gépeket vagy más szolgáltatásokat tartalmazó bizonyos hálózatok hozzáférésének létrehozására és kezelésére.
Ha egy virtuális hálózatból virtuális hálózati szabállyal konfigurálja a hozzáférést, akkor az ebben a virtuális hálózatban lévő összes erőforrás hozzáférhet a logikai Azure SQL Database-kiszolgálóhoz. Ezen a módon egyszerűbb konfigurálni az adatokhoz való hozzáférést az összes statikus és dinamikus IP-cím számára, amelynek a hozzáférésre szüksége van. Virtuális hálózati szabályok használatával egy vagy több virtuális hálózatot adhat meg, ez pedig az azokban lévő összes erőforrásra vonatkozik. Használatba veheti a hálózatokat Azure-régiók között, vagy akár a helyszínnel összekapcsoló virtuális hálózati technológiákat is.
Ebben a példában is lefuttathatná az előző szakaszban már látott lekérdezést az SQLDBVNET-EUS virtuális hálózatban lévő Azure-beli virtuális gépről:
SELECT client_net_address FROM sys.dm_exec_connections WHERE session_id=@@SPID;
Ennek eredménye 10.0.0.2, tehát az Azure-beli virtuális gép privát IP-címe. Ezzel az eredménnyel egy lépéssel közelebb jut logikai Azure SQL Database-kiszolgáló privát kapcsolatainak kialakításához, hiszen az erőforrások már a virtuális hálózaton keresztül kapcsolódnak.
A kapcsolat elemzésének egy másik elterjedt stratégiája a tartománynévrendszer (DNS) hierarchiájának vizsgálata. Ugyanezen az Azure-beli virtuális gépen kiadhatja az alábbi parancsot egy parancssorban:
nslookup aw-server.database.windows.net
Ezzel a paranccsal a DNS-infrastruktúrával kapcsolatos részletes információkhoz juthat hozzá. Az eredmények a következőhöz hasonlóak lehetnek:
Server: Unknown
Address: 168.63.129.16
Non-authoritative answer:
Name: cr2.eastus1-a.control.database.windows.net
Address: 174.17.218.16
Aliases: aw-server.database.windows.net
dataslice2.eastus.database.windows.net
A nem mérvadó válasz alatt van néhány fontos szempont:
- Név: A végpont a
cr2nyilvános DNS-hierarchia része. Anélkül, hogy túl sok lenne a hierarchia, tegyük fel, hogycr2ez a 2 . vezérlőgyűrű, és több adat "szelet" található alatta. - Cím: Az itt visszaadott IP-címnek meg kell egyeznie az Azure-beli virtuális gép nyilvános IP-címével. Bár egy eszköz, például az SSMS végső ugrása a virtuális gép magánhálózati IP-címén keresztül lehetséges, a virtuális gép nyilvános IP-címe továbbra is használható a csatlakozásra bizonyos kapacitásban.
- Aliasok: Az aliasok a DNS-hierarchia különböző pontjai, ebben az esetben az adott adat "szelete" és végpontja, amelyhez csatlakozik.
Megjegyzés:
Az előző kimeneti blokkban a Cím: 168.63.129.16 egy virtuális nyilvános IP-cím, amely az Azure-platform erőforrásaival való kommunikáció megkönnyítésére szolgál. Ez minden régióra és az összes országos felhőre vonatkozik, és nem fog megváltozni.
Bár az SSMS-kapcsolat az Azure-beli virtuális gép magánhálózati IP-címén keresztül jön létre, végső soron egy nyilvános végponton keresztül csatlakozik.
Private Link egy Azure SQL Database-hez
Láthatta, hogyan konfigurálhatja a legbiztonságosabb hálózatot az Azure SQL Database-ben lévő adatbázis nyilvános végponttal való használatával. Az adatbázisok SQL Database-beli biztonságossá tételének ez a módszerét évek óta használják. Az Azure azonban 2019-ben megkezdte az átállást az úgynevezett privát kapcsolatokra, amelyek még jobban hasonlítanak a felügyelt Azure SQL-példány üzembe helyezési módjához. Az Azure Private Link használatával privát végpont használatával csatlakozhat az adatbázishoz az SQL Database-ben és számos más, szolgáltatásként nyújtott platformalapú (PaaS-) ajánlathoz. Ez azt jelenti, hogy egy adott virtuális hálózaton belül privát IP-címe lesz.
Az előző példában láthatja, hogy az általános hálózati infrastruktúra nem változott, és továbbra is alkalmazhatja a virtuális hálózati csatlakozási stratégiákat a virtuális hálózati szabályokból. Ehhez azonban nem kell virtuális hálózati szabályokat létrehoznia. Azoknak az erőforrásoknak, amelyeknek csatlakozniuk kell az adatbázis-kiszolgálóhoz, ahhoz a virtuális hálózathoz kell hozzáférniük , amelyben a végpont található. A példában a végpont az SQLDBVNet-EUS. Csak a privát végponton áthaladó kapcsolatok kapnak hozzáférést, minden más (például internetes) kapcsolat meg van tagadva.
Ahogy folytatja ezt a példát, a virtuális hálózat SQLDBVNet-EUSazure-beli virtuális gépén ismét futtathatja a következő T-SQL-parancsot:
SELECT client_net_address FROM sys.dm_exec_connections WHERE session_id=@@SPID;
Az eredmény most az lesz 10.0.0.2, amely az Azure-beli virtuális gép magánhálózati IP-címe ebben a példában. A virtuális hálózatról való hozzáférés hozzáadásával úgy tűnik, hogy a virtuális gépről az Azure SQL Database-hez való kapcsolatok a virtuális gép magánhálózati IP-címén keresztül fognak érkezni. Ugyanezt az eredményt érte el virtuális hálózati szabályokkal is.
Érdemes lehet azonban megvizsgálni a DNS-hierarchiát a parancssorban kiadott alábbi paranccsal:
nslookup aw-server.database.windows.net
Ha fenti parancsot használja, az eredmény a privát végpont konfigurálása után egy kissé eltér az előzőtől:
Server: Unknown
Address: 168.63.129.16
Non-authoritative answer:
Name: aw-server.privatelink.database.windows.net
Address: 10.0.0.5
Aliases: aw-server.database.windows.net
A nem mérvadó válasz alatt van néhány fontos szempont:
- Név: Vegye figyelembe, hogy már nem a nyilvános DNS-hierarchiára mutat, csak a Private Link DNS-re. Ez azt jelenti, hogy kevesebb információt fed fel az adatbázis-kiszolgálóról.
- Címek: A virtuális hálózati szabályok esetében a visszaadott cím a virtuális gép nyilvános IP-címe, de most már egy vagy több privát IP-címnek kell lennie a Private Link-hierarchiában (az egyik az Azure SQL Database privát végpontja).
- Aliasok: A Név mezőhöz hasonlóan semmi sem kapcsolódik a DNS-hierarchiához, kivéve, hogy továbbra is csatlakozhat a kiszolgáló nevéhez (például
aw-server.database.windows.net).
Az egyik dolog, amire kíváncsi, hogy csatlakozik-e a privát végponthoz, miért használja még mindig ugyanazt a kiszolgálónevet? A háttérrendszerben, ha csak a Private Link metódust használja az Azure SQL Database-hez való csatlakozáshoz (azaz nincs tűzfal vagy virtuális hálózati szabály), a rendszer az alábbi módon dolgozza fel az adatokat:
aw-server.database.windows.net- A szolgáltatás által feloldva a következőre:
aw-server.privatelink.database.net- A szolgáltatás által feloldva a következőre:
10.0.0.5(a privát végpont IP-címe)
- A szolgáltatás által feloldva a következőre:
- A szolgáltatás által feloldva a következőre:
A szolgáltatás az aw-server.database.windows.net kivételével mindenhonnan le is tiltja a közvetlen kapcsolódást.
Access management
Miután kidolgozta a hálózati hozzáférést, a következő megfontolandó réteg a hozzáférés-kezelés.
Szerepköralapú hozzáférés-vezérlés
Az Azure SQL Database összes Azure-beli művelettípusát szerepköralapú hozzáférés-vezérlés (RBAC) vezérli. Az RBAC jelenleg leválasztva van az Azure SQL-biztonságról, de az SQL Database-ben az adatbázison kívüli biztonsági jogosultságokként is felfogható, amely az előfizetést, az erőforráscsoportot és az erőforrást is magában foglalja. Ezek a jogok vonatkoznak az Azure Portalon, az Azure CLI-ben és az Azure PowerShellben végzett műveletekre is. Az RBAC lehetővé teszi az üzembe helyezési, felügyeleti és használati feladatok elkülönítését.
Beépített szerepkörök állnak rendelkezésre a magasabb szintű RBAC-szerepkörök, például a Tulajdonos vagy a Közreműködő iránti igény csökkentéséhez. Ezeket a szerepköröket hatékonyan használhatja arra, hogy bizonyos személyek Azure SQL-erőforrásokat telepítsenek (vagy biztonsági szabályzatokat kezelhessenek), de tényleges hozzáférést biztosíthat más felhasználóknak az adatbázis használatához vagy kezeléséhez. Egy SQL Server-közreműködő például üzembe helyezhet egy kiszolgálót, és hozzárendelhet egy felhasználót a kiszolgáló és az adatbázisok rendszergazdájához. Az Azure SQL Database beépített szerepkörei a következők:
- SQL DB-közreműködő: Létrehozhat és kezelhet adatbázisokat, de nem fér hozzá az adatbázishoz (például nem tud adatokat csatlakozni és olvasni)
- SQL Security Manager: Kezelheti az adatbázisok és példányok biztonsági szabályzatait (például a naplózást), de nem tudja elérni őket
- SQL Server-közreműködő: Kezelheti a kiszolgálókat és az adatbázisokat, de nem tudja elérni őket.
Hitelesítés
Az Azure SQL Database logikai kiszolgáló üzembe helyezése során a következő hitelesítési módszert adhatja meg:
- Csak Microsoft Entra-hitelesítés használata
- SQL- és Microsoft Entra-hitelesítés használata
- SQL-hitelesítés használata
A kiszolgáló rendszergazdájának be kell állítania az üzembe helyezés során. Az Azure SQL Database-ben lévő adatbázisok esetében a kiszolgáló rendszergazdája az Azure SQL Database logikai kiszolgáló kiszolgálószintű egyszerű kiszolgálója.
Ha Olyan számítási feladatot migrál, amely Windows-hitelesítést igényel, vagy a szervezete Microsoft Entra-azonosítót használ, használhatja a Microsoft Entra-azonosítót. Microsoft Entra-kiszolgáló rendszergazdáját a portálon vagy a parancssori eszközökkel rendelheti hozzá.
Új kiszolgáló konfigurálásakor a csak Microsoft Entra hitelesítés az alapértelmezett beállítás. A kiszolgálói bejelentkezések lehetővé teszik a Microsoft Entra-kiszolgálónevek használatát, amelyek az SQL Database virtuális master adatbázisában való bejelentkezések. Microsoft Entra-bejelentkezéseket microsoft entra-felhasználókból , csoportokból és szolgáltatásnevekből hozhat létre. Ha csak Microsoft Entra-hitelesítést használ, sql-hitelesítési bejelentkezéseket hozhat létre, és a meglévő bejelentkezések megmaradnak. A logikai kiszolgálóhoz azonban csak a Microsoft Entra hitelesítési bejelentkezései és felhasználói csatlakozhatnak. A csak Microsoft Entra-hitelesítéssel kapcsolatos további információkért lásd : Microsoft Entra-only authentication with Azure SQL.
Attól függően, hogy szervezete hogyan konfigurálta a Microsoft Entra-példányt, az alábbi három módszer (például az SSMS) bármelyikével csatlakozhat hozzá:
Microsoft Entra ID – Integrált: Nem interaktív módszer, amelyet akkor használhat, ha összevont tartományból jelentkezett be a Windowsba a Microsoft Entra hitelesítő adataival.
Microsoft Entra ID – Jelszó: Nem interaktív módszer, amely lehetővé teszi a Microsoft Entra egyszerű nevével való kapcsolódást a Microsoft Entra ID által felügyelt tartomány használatával. Idézet a dokumentációból:
Ez a natív vagy összevont Microsoft Entra-felhasználókra is vonatkozhat. A natív felhasználók kifejezetten a Microsoft Entra-azonosítóban jönnek létre, és felhasználónévvel és jelszóval hitelesítik őket, míg az összevont felhasználó olyan Windows-felhasználó, akinek a tartománya Microsoft Entra-azonosítóval van összevonva. Az utóbbi módszer (felhasználónév és jelszó használatával) akkor használható, ha a felhasználó használni szeretné a windowsos hitelesítő adatait, de a helyi gépe nem csatlakozik a tartományhoz (például táveléréssel). Ebben az esetben a Windows-felhasználók megjelölhetik a tartományfiókjukat és a jelszavukat, és összevont hitelesítő adatokkal hitelesíthetik magukat az SQL Database-ben vagy az Azure Synapse Analyticsben (korábban SQL DW).
Microsoft Entra ID – Univerzális többtényezős hitelesítéssel (MFA): Interaktív módszer, amely biztosítja az adatokhoz való hozzáférést, miközben kielégíti a szervezet egyetlen bejelentkezési folyamatra vonatkozó igényét a Microsoft Entra többtényezős hitelesítésével.
Az Azure SQL Database esetében van néhány árnyalat. A virtuális master adatbázisban, az adatbázis felhasználóiban és a Microsoft Entra-fiókok adatbázis-felhasználóiban is lehetnek bejelentkezések (ajánlott). Bár az Azure SQL Database kiszolgálói rendszergazdája alapvetően rendelkezik sysadmin jogosultságokkal, korlátozottabb rendszergazdákat hozhat létre kiszolgálói vagy adatbázisszintű szerepkörök használatával. Két adatbázisszintű szerepkör érhető el az SQL Database-hez, amelyek csak a virtuális master adatbázisban léteznek:
- loginmanager: Adatbázisszintű szerepkör, amely lehetővé teszi a tagok számára, hogy bejelentkezéseket hozzanak létre az adatbázis-kiszolgálóhoz
- dbmanager: Adatbázisszintű szerepkör, amely lehetővé teszi a tagok számára, hogy adatbázisokat hozzanak létre és töröljenek az adatbázis-kiszolgálóhoz
Íme az Azure SQL Database kiszolgálószintű szerepköreinek listája:
- ##MS_DatabaseCsatlakozás or##
- ##MS_DatabaseManager##
- ##MS_DefinitionReader##
- ##MS_LoginManager##
- ##MS_SecurityDefinitionReader##
- ##MS_ServerStateReader##
- ##MS_ServerStateManager##
Végezetül, a hitelesítés és engedélyezés beállításhoz és konfigurálásához négy irányelvet követve járhat el:
- Üzembe helyezés kiszolgálói rendszergazdaként
- Szükség esetén további rendszergazdák létrehozása
- A rendszergazdák létrehozhatnak felhasználókat
- Hozzáférések megadása ugyanúgy, ahogyan az SQL Serverben tenné
Egyéb lehetőségek
Miután szert tett némi gyakorlatra a hálózati és hitelesítési képességek egy részével, a modul későbbi részeiben más adatvédelmi, figyelési, naplózási és auditálási képességekkel (és az azokhoz kapcsolódó tevékenységekkel) is megismerkedhet.