Megosztás a következőn keresztül:

Forgatókönyv az Azure SQL Database és a felügyelt Azure SQL-példány gyakori biztonsági követelményeinek kezeléséhez

  • Cikk

A következőre vonatkozik: Azure SQL DatabaseFelügyelt Azure SQL-példány

Ez a cikk a gyakori biztonsági követelmények megoldásának ajánlott eljárásait ismerteti. Nem minden követelmény vonatkozik az összes környezetre, ezért forduljon az adatbázishoz és a biztonsági csapathoz, hogy mely szolgáltatásokat kell implementálnia.

Megjegyzés:

A Microsoft Entra ID az Azure Active Directory (Azure AD) új neve. Jelenleg frissítjük a dokumentációt.

Gyakori biztonsági követelmények megoldása

Ez a dokumentum útmutatást nyújt az új vagy meglévő alkalmazások általános biztonsági követelményeinek megoldásához az Azure SQL Database és az Azure SQL Managed Instance használatával. Magas szintű biztonsági területek szerint van rendszerezve. Az egyes fenyegetések kezeléséhez tekintse meg a Közös biztonsági fenyegetések és a lehetséges kockázatcsökkentések szakaszt . Bár a bemutatott javaslatok némelyike alkalmazható az alkalmazások helyszíni környezetből az Azure-ba való migrálásakor, a dokumentum nem a migrálási forgatókönyvekre összpontosít.

Az Azure SQL Database jelen útmutatóban ismertetett üzembehelyezési ajánlatai

Az útmutatóban nem szereplő üzembehelyezési ajánlatok

  • Azure Synapse Analytics
  • Azure SQL-beli virtuális gépek (IaaS)
  • SQL Server

Célközönség

Az útmutató célközönsége kérdéseket vet fel az Azure SQL Database biztonságossá tételével kapcsolatban. Az ajánlott eljárásokat ismertető cikkben szereplő szerepkörök többek között a következők:

  • Biztonsági tervezők
  • Biztonsági vezetők
  • Megfelelőségi tisztviselők
  • Adatvédelmi tisztviselők
  • Biztonsági mérnökök

Az útmutató használata

Ez a dokumentum a meglévő Azure SQL Database biztonsági dokumentációnk kísérője.

Ha másként nem rendelkezik, javasoljuk, hogy kövesse az egyes szakaszokban felsorolt ajánlott eljárásokat a megfelelő cél vagy követelmény eléréséhez. Az adott biztonsági megfelelőségi szabványoknak vagy ajánlott eljárásoknak való megfelelés érdekében a fontos szabályozási megfelelőségi ellenőrzések a Követelmények vagy célok szakaszban jelennek meg, ahol csak lehetséges. Ezek a jelen dokumentumban hivatkozott biztonsági szabványok és szabályozások:

Tervezzük, hogy továbbra is frissítjük az itt felsorolt javaslatokat és ajánlott eljárásokat. Adjon meg bemenetet vagy javításokat a dokumentumhoz a cikk alján található Visszajelzés hivatkozás használatával.

Authentication

Authentication is the process of proving the user is who they claim to be. Az Azure SQL Database és a felügyelt SQL-példány kétféle hitelesítést támogat:

  • SQL authentication
  • Microsoft Entra authentication

Megjegyzés:

Előfordulhat, hogy a Microsoft Entra-hitelesítés nem támogatott minden eszközhöz és külső alkalmazáshoz.

Identitások központi kezelése

A központi identitáskezelés a következő előnyöket nyújtja:

  • Csoportfiókok kezelése és felhasználói engedélyek szabályozása a bejelentkezések kiszolgálókon, adatbázisokon és felügyelt példányokon történő duplikálása nélkül.
  • Egyszerűsített és rugalmas engedélykezelés.
  • Alkalmazások nagy léptékű kezelése.

Implementálás

  • Microsoft Entra-hitelesítés használata központosított identitáskezeléshez.

Best practices

  • Hozzon létre egy Microsoft Entra-bérlőt, és hozzon létre felhasználókat, hogy az emberi felhasználókat képviselje, és szolgáltatásneveket hozzon létre az alkalmazások, szolgáltatások és automatizálási eszközök megjelenítéséhez. A szolgáltatásnevek egyenértékűek a Windows és a Linux szolgáltatásfiókjaival.

  • Hozzáférési jogosultságok hozzárendelése erőforrásokhoz a Microsoft Entra-tagokhoz csoporthozzárendeléssel: Microsoft Entra-csoportok létrehozása, csoportokhoz való hozzáférés biztosítása és egyéni tagok hozzáadása a csoportokhoz. Az adatbázisban hozzon létre olyan tartalmazott adatbázis-felhasználókat, amelyek megfeleltetik a Microsoft Entra-csoportokat. Az adatbázison belüli engedélyek hozzárendeléséhez adja hozzá a csoportokat képviselő tárolt adatbázis-felhasználókat az adatbázis-szerepkörökhöz, vagy adjon nekik közvetlenül engedélyeket.

    Megjegyzés:

    A felügyelt SQL-példányban olyan bejelentkezéseket is létrehozhat, amelyek az adatbázisban lévő Microsoft Entra-tagokhoz lesznek megfeleltetve master . Lásd: CREATE LOGIN (Transact-SQL).

  • A Microsoft Entra-csoportok használata leegyszerűsíti az engedélykezelést és a csoporttulajdonost is, és az erőforrás-tulajdonos tagokat vehet fel/távolíthat el a csoportból.

  • Hozzon létre egy külön csoportot a Microsoft Entra rendszergazdái számára minden kiszolgálóhoz vagy felügyelt példányhoz.

  • A Microsoft Entra-csoporttagság változásainak monitorozása a Microsoft Entra ID naplózási tevékenységjelentéseivel.

  • Felügyelt példány esetén külön lépésre van szükség a Microsoft Entra rendszergazdájának létrehozásához.

Megjegyzés:

  • A Microsoft Entra-hitelesítés az Azure SQL auditnaplóiban van rögzítve, de a Microsoft Entra bejelentkezési naplóiban nem.
  • Az Azure-ban megadott Azure RBAC-engedélyek nem vonatkoznak az Azure SQL Database-re vagy a felügyelt SQL-példányokra. Ezeket az engedélyeket manuálisan kell létrehozni/leképezni a meglévő SQL-engedélyek használatával.
  • Ügyféloldalon a Microsoft Entra-hitelesítésnek hozzáférésre van szüksége az internethez vagy a felhasználó által megadott útvonalon (UDR) keresztül egy virtuális hálózathoz.
  • A Microsoft Entra hozzáférési jogkivonat gyorsítótárazva van az ügyféloldalon, és élettartama a jogkivonat konfigurációjától függ. Lásd a Microsoft Entra ID konfigurálható jogkivonat-élettartamait ismertető cikket
  • A Microsoft Entra hitelesítési problémáinak elhárításával kapcsolatos útmutatásért tekintse meg a következő blogot: A Microsoft Entra-azonosító hibaelhárítása.

Microsoft Entra többtényezős hitelesítés

Az alábbiakban említettük: OSA 2. gyakorlat, ISO-hozzáférés-vezérlés (AC)

A Microsoft Entra többtényezős hitelesítés többtényezős hitelesítése több hitelesítési mód megkövetelésével további biztonságot nyújt.

Implementálás

  • Engedélyezze a többtényezős hitelesítést a Microsoft Entra-azonosítóban feltételes hozzáféréssel, és használjon interaktív hitelesítést.

  • A másik lehetőség a többtényezős hitelesítés engedélyezése a teljes Microsoft Entra-bérlő vagy Active Directory-tartomány esetében.

Best practices

  • Feltételes hozzáférés aktiválása a Microsoft Entra-azonosítóban (prémium szintű előfizetést igényel).

    • Lásd a Feltételes hozzáférés a Microsoft Entra ID-ban című cikket.

  • Hozzon létre Microsoft Entra-csoportokat, és engedélyezze a többtényezős hitelesítési házirendet a kijelölt csoportokhoz a Microsoft Entra feltételes hozzáféréssel.

  • A többtényezős hitelesítés a teljes Microsoft Entra-bérlő vagy a Microsoft Entra-azonosítóval összevont Active Directory esetében engedélyezhető.

  • Használja a Microsoft Entra interaktív hitelesítési módot az Azure SQL Database-hez és a felügyelt Azure SQL-példányhoz, ahol a rendszer interaktívan kéri a jelszót, majd a többtényezős hitelesítést:

  • Alkalmazások implementálása az Azure SQL Database-hez vagy a felügyelt Azure SQL-példányhoz való csatlakozáshoz interaktív hitelesítéssel, többtényezős hitelesítés támogatásával.

    Megjegyzés:

    Ehhez a hitelesítési módhoz felhasználói identitások szükségesek. Azokban az esetekben, amikor olyan megbízható identitásmodellt használnak, amely megkerüli az egyes Microsoft Entra felhasználói hitelesítést (például felügyelt identitást használ az Azure-erőforrásokhoz), a többtényezős hitelesítés nem érvényes.

Jelszóalapú hitelesítés használatának minimalizálása a felhasználók számára

Az alábbiakban említettük: OSA 4. gyakorlat, ISO-hozzáférés-vezérlés (AC)

A jelszóalapú hitelesítési módszerek a hitelesítés egy gyengébb formája. A hitelesítő adatok feltörhetők vagy tévesen átadhatók.

Implementálás

  • Használjon integrált Microsoft Entra-hitelesítést, amely megszünteti a jelszavak használatát.

Best practices

  • Egyszeri bejelentkezéses hitelesítés használata Windows-hitelesítő adatokkal. Fedje össze a helyi Active Directory tartományt a Microsoft Entra-azonosítóval, és használjon integrált Windows-hitelesítést (tartományhoz csatlakoztatott gépekhez a Microsoft Entra ID azonosítóval).

Jelszóalapú hitelesítés használatának minimalizálása alkalmazásokhoz

Az alábbiakban említettük: OSA 4. gyakorlat, ISO-hozzáférés-vezérlés (AC)

Implementálás

  • Az Azure Managed Identity engedélyezése. Integrált vagy tanúsítványalapú hitelesítést is használhat.

Best practices

Jelszavak és titkos kódok védelme

Olyan esetekben, amikor a jelszavak nem kerülhetők el, győződjön meg arról, hogy biztonságosak.

Implementálás

  • Az Azure Key Vault használatával jelszavakat és titkos kulcsokat tárolhat. Ha lehetséges, többtényezős hitelesítést használjon az Azure SQL Database-hez a Microsoft Entra-felhasználókkal.

Best practices

  • Ha a jelszavak vagy titkos kódok elkerülése nem lehetséges, tárolja a felhasználói jelszavakat és az alkalmazás titkos kulcsait az Azure Key Vaultban, és kezelje a hozzáférést a Key Vault hozzáférési szabályzatain keresztül.

  • A különböző alkalmazásfejlesztési keretrendszerek keretrendszerspecifikus mechanizmusokat is kínálhatnak az alkalmazásban lévő titkos kódok védelmére. Például: ASP.NET alapalkalmazás.

SQL-hitelesítés használata örökölt alkalmazásokhoz

Az SQL-hitelesítés egy felhasználó hitelesítésére utal, amikor felhasználónévvel és jelszóval csatlakozik az Azure SQL Database-hez vagy a felügyelt SQL-példányhoz. Minden kiszolgálón vagy felügyelt példányban létre kell hoznia egy bejelentkezést, és létre kell hoznia egy felhasználót az egyes adatbázisokban.

Implementálás

  • SQL-hitelesítés használata.

Best practices

Access management

A hozzáférés-kezelés (más néven engedélyezés) az Engedélyezett felhasználók hozzáférésének és jogosultságainak szabályozása és kezelése az Azure SQL Database-hez vagy a felügyelt SQL-példányhoz.

A minimális jogosultság elvének megvalósítása

Megemlítve: FedRamp controls AC-06, NIST: AC-6, OSA Practice #3

A minimális jogosultság elve azt állítja, hogy a felhasználóknak nem szabad több jogosultsággal rendelkezniük, mint amennyi szükséges a feladataik elvégzéséhez. További információkért lásd a Megfelelő adminisztráció című cikket.

Implementálás

Csak a szükséges engedélyek hozzárendelése a szükséges feladatok elvégzéséhez:

Best practices

Az alábbi ajánlott eljárások nem kötelezőek, de jobb kezelhetőséget és a biztonsági stratégia támogatottságát eredményezik:

  • Ha lehetséges, kezdje a lehető legkisebb engedélykészlettel, és kezdje el egyenként hozzáadni az engedélyeket, ha valódi szükség van rá (és indoklás) – szemben az ellenkező megközelítéssel: az engedélyek lépésről lépésre történő elvétele.

  • Ne rendeljen engedélyeket az egyes felhasználókhoz. Használjon szerepköröket (adatbázis- vagy kiszolgálószerepköröket) következetesen. A szerepkörök nagyban segítenek a jelentéskészítésben és a hibaelhárításban. (Az Azure RBAC csak szerepkörökön keresztül támogatja az engedély-hozzárendelést.)

  • Hozzon létre és használjon egyéni szerepköröket a szükséges pontos engedélyekkel. A gyakorlatban használt tipikus szerepkörök:

    • Biztonsági üzembe helyezés
    • Rendszergazda
    • Fejlesztő
    • Támogatási személyzet
    • Könyvvizsgáló
    • Automatizált folyamatok
    • Végfelhasználó

  • Csak akkor használjon beépített szerepköröket, ha a szerepkörök engedélyei pontosan megegyeznek a felhasználó számára szükséges engedélyekkel. A felhasználókat több szerepkörhöz is hozzárendelheti.

  • Ne feledje, hogy az adatbázismotor engedélyei a következő hatókörökben alkalmazhatók (minél kisebb a hatókör, annál kisebb a megadott engedélyek hatása):

    • Kiszolgáló (speciális szerepkörök az adatbázisban) az master Azure-ban
    • Database
    • Séma
      • Ajánlott sémákat használni az adatbázisokon belüli engedélyek megadásához.
    • Objektum (tábla, nézet, eljárás stb.)

    Megjegyzés:

    Nem ajánlott engedélyeket alkalmazni az objektum szintjén, mert ez a szint szükségtelen bonyolultságot ad a teljes megvalósításhoz. Ha úgy dönt, hogy objektumszintű engedélyeket használ, azokat egyértelműen dokumentálni kell. Ugyanez vonatkozik az oszlopszintű engedélyekre is, amelyek ugyanazon okokból még kevésbé ajánlottak. Vegye figyelembe azt is, hogy a táblaszintű DENY alapértelmezés szerint nem bírálja felül az oszlopszintű GRANT függvényt. Ehhez aktiválni kell a közös feltételmegfelelési kiszolgáló konfigurációját .

  • Végezzen rendszeres ellenőrzéseket a sebezhetőségi felmérés (VA) használatával a túl sok engedély teszteléséhez.

A vámok elkülönítésének megvalósítása

Megemlítve: FedRamp: AC-04, NIST: AC-5, ISO: A.6.1.2, PCI 6.4.2, SOC: CM-3, SDL-3

A feladatok elkülönítése, más néven a feladatok elkülönítése azt a követelményt írja le, hogy a bizalmas tevékenységeket több, különböző felhasználókhoz rendelt tevékenységre kell felosztani. A feladatok elkülönítése segít megelőzni az adatsértéseket.

Implementálás

  • Azonosítsa a feladatok elkülönítésének szükséges szintjét. Examples:

    • Fejlesztési/tesztelési és éles környezetek között
    • Biztonsági szempontból érzékeny feladatok és adatbázis-Rendszergazda istrator (DBA) felügyeleti szintű feladatok és fejlesztői feladatok.
      • Példák: Auditor, biztonsági szabályzat létrehozása szerepkörszintű biztonsághoz (RLS), SQL Database-objektumok implementálása DDL-engedélyekkel.

  • A rendszerhez hozzáférő felhasználók (és automatizált folyamatok) átfogó hierarchiájának azonosítása.

  • Hozzon létre szerepköröket a szükséges felhasználói csoportoknak megfelelően, és rendeljen hozzá engedélyeket a szerepkörökhöz.

    • Az Azure Portalon vagy a PowerShell-automatizáláson keresztül végzett felügyeleti szintű feladatokhoz használja az Azure-szerepköröket. Keresse meg a követelménynek megfelelő beépített szerepkört, vagy hozzon létre egy Egyéni Azure-szerepkört a rendelkezésre álló engedélyek használatával
    • Kiszolgálói szerepkörök létrehozása kiszolgálószintű feladatokhoz (új bejelentkezések, adatbázisok létrehozása) egy felügyelt példányban.
    • Adatbázis-szerepkörök létrehozása adatbázisszintű feladatokhoz.

  • Bizonyos bizalmas feladatok esetében fontolja meg a tanúsítványok által aláírt speciális tárolt eljárások létrehozását a feladatok a felhasználók nevében történő végrehajtásához. A digitálisan aláírt tárolt eljárások egyik fontos előnye, hogy az eljárás módosítása esetén az eljárás korábbi verziójához kapott engedélyek azonnal törlődnek.

  • A transzparens adattitkosítás (TDE) implementálása ügyfél által felügyelt kulcsokkal az Azure Key Vaultban, hogy lehetővé tegye a feladatok elkülönítését az adattulajdonos és a biztonsági tulajdonos között.

    • Tekintse meg az Azure Storage-titkosítás ügyfél által felügyelt kulcsainak konfigurálása az Azure Portalról című cikket.

  • Annak érdekében, hogy a DBA ne láthassa a rendkívül bizalmasnak tekintett adatokat, és továbbra is el tudja végezni a DBA-feladatokat, használhatja az Always Encryptedt szerepkör-elkülönítéssel.

  • Azokban az esetekben, amikor az Always Encrypted használata nem kivitelezhető, vagy legalábbis nem jelentős költségek és erőfeszítések nélkül, amelyek akár használhatatlanná is tehetik a rendszert, kompromisszumok hozhatók és csökkenthetők kompenzáló vezérlők használatával, például:

    • Emberi beavatkozás folyamatokba.
    • Naplózási naplók – a naplózással kapcsolatos további információkért lásd: Kritikus biztonsági események naplózása.

Best practices

  • Győződjön meg arról, hogy különböző fiókokat használnak fejlesztési/tesztelési és éles környezetekhez. A különböző fiókok segítenek megfelelni a tesztelési és éles rendszerek elkülönítésének.

  • Ne rendeljen engedélyeket az egyes felhasználókhoz. Használjon szerepköröket (adatbázis- vagy kiszolgálószerepköröket) következetesen. A szerepkörök nagyban segítenek a jelentéskészítésben és a hibaelhárításban.

  • Beépített szerepköröket akkor használjon, ha az engedélyek pontosan megfelelnek a szükséges engedélyeknek – ha a több beépített szerepkör összes engedélyének egyesítése 100%-os egyezést eredményez, egyszerre több szerepkört is hozzárendelhet.

  • Felhasználó által definiált szerepkörök létrehozása és használata, ha a beépített szerepkörök túl sok engedélyt vagy nem megfelelő engedélyeket adnak meg.

  • A szerepkör-hozzárendelések ideiglenesen is elvégezhetők, más néven a feladatok dinamikus elkülönítése (DSD) a T-SQL SQL SQL-ügynök feladatának lépésein belül, vagy Azure-szerepkörökhöz az Azure PIM használatával.

  • Győződjön meg arról, hogy a adatbázis-kezelők nem férnek hozzá a titkosítási kulcsokhoz vagy kulcstárolókhoz, és hogy a kulcsokhoz hozzáféréssel rendelkező biztonsági Rendszergazda istratorok nem férnek hozzá az adatbázishoz. Az Extensible Key Management (EKM) használata egyszerűbbé teheti ezt az elkülönítést. Az Azure Key Vault használható az EKM implementálásához.

  • Mindig győződjön meg arról, hogy rendelkezik auditnaplóval a biztonsággal kapcsolatos műveletekhez.

  • Az Azure beépített szerepköreinek definícióját lekérve megtekintheti a használt engedélyeket, és létrehozhat egy egyéni szerepkört ezek kivonatai és kumulációi alapján a PowerShell-lel.

  • Mivel a db_owner adatbázis-szerepkör bármely tagja módosíthatja az olyan biztonsági beállításokat, mint a transzparens adattitkosítás (TDE), vagy módosíthatja az SLO-t, ezt a tagságot körültekintően kell biztosítani. Azonban számos olyan feladat van, amely db_owner jogosultságot igényel. Olyan feladat, mint bármely adatbázis-beállítás módosítása, például a DB-beállítások módosítása. A naplózás kulcsszerepet játszik minden megoldásban.

  • A db_owner engedélyei nem korlátozhatóak, ezért megakadályozhatják, hogy egy rendszergazdai fiók megtekintse a felhasználói adatokat. Ha egy adatbázisban nagyon bizalmas adatok találhatók, az Always Encrypted használatával biztonságosan megakadályozhatja, hogy db_owners vagy bármely más DBA megtekintse őket.

Megjegyzés:

A feladatok elkülönítésének (SoD) elérése kihívást jelent a biztonsággal kapcsolatos vagy hibaelhárítási feladatok esetében. Más területek, például a fejlesztés és a végfelhasználói szerepkörök könnyebben elkülöníthetők. A megfelelőséghez kapcsolódó vezérlők többsége lehetővé teszi az olyan alternatív vezérlőfunkciók használatát, mint a naplózás, ha más megoldások nem praktikusak.

Azoknak az olvasóknak, akik részletesebben szeretnének megismerkedni a SoD-nal, a következő erőforrásokat javasoljuk:

Rendszeres kódvizsgálatok végrehajtása

Megemlítve: PCI: 6.3.2, SOC: SDL-3

A feladatok elkülönítése nem korlátozódik az adatbázisban lévő adatokra, hanem alkalmazáskódot is tartalmaz. A rosszindulatú kódok esetleg megkerülhetik a biztonsági vezérlőket. Az egyéni kód éles környezetben való üzembe helyezése előtt fontos áttekinteni az üzembe helyezett kódot.

Implementálás

  • Használjon olyan adatbázis-eszközt, mint az Azure Data Studio, amely támogatja a forrásvezérlést.

  • Szegregált kódtelepítési folyamat implementálása.

  • A főágra való véglegesítés előtt egy személynek (a kód szerzőén kívül) meg kell vizsgálnia a kódot a jogosultságok esetleges emelési kockázatainak, valamint a rosszindulatú adatmódosításoknak a csalások és a gazemberek hozzáférése elleni védelem érdekében. Ez a forrásvezérlési mechanizmusokkal végezhető el.

Best practices

  • Szabványosítás: Segít a kódfrissítésekhez követendő szabványos eljárás implementálásában.

  • A sebezhetőségi felmérés olyan szabályokat tartalmaz, amelyek ellenőrzik a túlzott engedélyeket, a régi titkosítási algoritmusok használatát és az adatbázisséma egyéb biztonsági problémáit.

  • További ellenőrzések végezhetők minőségbiztosítási vagy tesztelési környezetben az Advanced Threat Protection használatával, amely olyan kódot keres, amely sebezhető az SQL-injektálással szemben.

  • Példák arra, hogy mire érdemes figyelni:

    • Felhasználó létrehozása vagy a biztonsági beállítások módosítása egy automatizált SQL-code-update üzembe helyezésből.
    • Tárolt eljárás, amely a megadott paraméterektől függően nem megfelelő módon frissíti a cella pénzügyi értékét.

  • Győződjön meg arról, hogy a felülvizsgálatot végző személy nem az eredeti kód szerzője, és a kódismétlésekben és a biztonságos kódolásban jártos.

  • Mindenképpen ismernie kell a kódmódosítások összes forrását. A kód lehet T-SQL-szkriptekben. A nézetek, függvények, triggerek és tárolt eljárások formájában végrehajtható vagy üzembe helyezhető alkalmi parancsok is lehetnek. Része lehet az SQL Agent feladatdefinícióinak (lépések). Az SSIS-csomagokból, az Azure Data Factoryből és más szolgáltatásokból is végrehajtható.

Adatvédelem

Az adatvédelem a fontos információk titkosítással vagy eltitkolással történő védelmére szolgáló képességek készlete.

Megjegyzés:

A Microsoft fiPS 140-2 1. szintű 1. szintűnek minősíti az Azure SQL Database-t és a felügyelt SQL-példányt. Ez a FIPS 140-2 1. szintű elfogadható algoritmusok és a FIPS 140-2 1. szintű ellenőrzött példányainak ellenőrzése után történik, beleértve a szükséges kulcshosszúságokkal való konzisztenciát, a kulcskezelést, a kulcsgenerálást és a kulcstárolást. Ez az igazolás lehetővé teszi ügyfeleink számára, hogy reagáljanak a FIPS 140-2 1. szintű hitelesített példányok az adatok feldolgozásában vagy a rendszerek vagy alkalmazások kézbesítésében való használatára vonatkozó igényre vagy követelményre. A fenti nyilatkozatban a "FIPS 140-2 Level 1 compliance" és a "FIPS 140-2 Level 1 compliance" kifejezéseket határozzuk meg, amelyek a "FIPS 140-2 Level 1 validált" kifejezésnek az amerikai és kanadai kormányzati használatra való tervezett alkalmazhatóságának bemutatására szolgálnak.

Átvitel alatt lévő adatok titkosítása

Az alábbiakban említettük: OSA 6. gyakorlat, ISO-vezérlőcsalád: Titkosítás

Védi az adatokat, miközben az adatok az ügyfél és a kiszolgáló között mozognak. Tekintse meg a Hálózati biztonság témakört.

Inaktív adatok titkosítása

Az alábbiakban említettük: OSA 6. gyakorlat, ISO-vezérlőcsalád: Titkosítás

Az inaktív adatok titkosítása az adatbázisokban, naplókban és biztonsági mentési fájlokban való megőrzésekor.

Implementálás

  • A szolgáltatás által felügyelt kulcsokkal rendelkező transzparens adattitkosítás (TDE) alapértelmezés szerint engedélyezve van az Azure SQL Database-ben és a felügyelt SQL-példányban 2017 után létrehozott adatbázisok esetében.
  • Felügyelt példányban, ha az adatbázis egy helyszíni kiszolgálóval történő visszaállítási műveletből jön létre, az eredeti adatbázis TDE-beállításának tiszteletben kell tartania. Ha az eredeti adatbázisban nincs engedélyezve a TDE, javasoljuk, hogy a TDE manuálisan legyen bekapcsolva a felügyelt példányhoz.

Best practices

  • Ne tárolja azokat az adatokat, amelyek titkosítást igényelnek az master adatbázisban. Az master adatbázis nem titkosítható TDE-vel.

  • Használjon ügyfél által felügyelt kulcsokat az Azure Key Vaultban, ha nagyobb átláthatóságra és részletes vezérlésre van szüksége a TDE-védelem felett. Az Azure Key Vault lehetővé teszi, hogy bármikor visszavonja az engedélyeket az adatbázis elérhetetlenné tétele érdekében. Központilag kezelheti a TDE-védőket más kulcsokkal együtt, vagy a TDE-védőt saját ütemezés szerint elforgathatja az Azure Key Vault használatával.

  • Ha ügyfél által felügyelt kulcsokat használ az Azure Key Vaultban, kövesse a TDE Azure Key Vaulttal való konfigurálására vonatkozó irányelveket, valamint a Geo-DR Azure Key Vaulttal való konfigurálását ismertető cikkeket.

Megjegyzés:

Egyes ügyféltartalmak, például a táblanevek, az objektumnevek és az indexnevek, a Microsoft támogatás és hibaelhárítás céljából a naplófájlokban továbbíthatók.

Bizalmas adatok védelme a magas jogosultságú, jogosulatlan felhasználóktól

A használatban lévő adatok az adatbázisrendszer memóriájában az SQL-lekérdezések végrehajtása során tárolt adatok. Ha az adatbázis bizalmas adatokat tárol, előfordulhat, hogy a szervezetnek gondoskodnia kell arról, hogy a kiemelt felhasználók ne tekinthessék meg a bizalmas adatokat az adatbázisban. A nagy jogosultsággal rendelkező felhasználóknak, például a Microsoft operátorainak vagy a szervezet adatbázis-kezelőinek képesnek kell lenniük kezelni az adatbázist, de nem tekinthetik meg és nem tudják kiszűrni a bizalmas adatokat az SQL-folyamat memóriájából, vagy lekérdezhetik az adatbázist.

Azok a szabályzatok, amelyek meghatározzák, hogy mely adatok bizalmasak, és hogy a bizalmas adatokat titkosítva kell-e titkosítani a memóriában, és hogy a rendszergazdák nem érhetik-e el egyszerű szövegként, a szervezeti és megfelelőségi előírásokra vonatkoznak, amelyeket be kell tartania. Tekintse meg a kapcsolódó követelményt: Bizalmas adatok azonosítása és címkézése.

Implementálás

  • Az Always Encrypted használatával biztosíthatja, hogy a bizalmas adatok ne legyenek egyszerű szövegben elérhetővé téve az Azure SQL Database-ben vagy a felügyelt SQL-példányban, még a memóriában vagy a használatban is. Az Always Encrypted védi az adatokat az adatbázis-Rendszergazda istratoroktól és a felhőgazdáktól (vagy olyan rossz szereplőktől, akik megszemélyesíthetik a magas jogosultságú, de jogosulatlan felhasználókat), és jobban szabályozhatja, hogy ki férhet hozzá az adataihoz.

Best practices

  • Az Always Encrypted nem helyettesíti az inaktív (TDE) vagy az átvitel alatt lévő (SSL/TLS) adatok titkosítását. Az Always Encrypted nem használható nem bizalmas adatokhoz a teljesítményre és a működésre gyakorolt hatás minimalizálása érdekében. Az Always Encrypted és a TDE és a Transport Layer Security (TLS) együttes használata ajánlott az inaktív, az átvitel alatt álló és a használaton kívüli adatok átfogó védelméhez.

  • Az Always Encrypted éles adatbázisban való üzembe helyezése előtt mérje fel az azonosított bizalmas adatoszlopok titkosításának hatását. Az Always Encrypted általában csökkenti a titkosított oszlopok lekérdezéseinek funkcióit, és egyéb korlátozásokkal is rendelkezik, amelyek az Always Encrypted – Funkció részletei listában találhatók. Ezért előfordulhat, hogy újra kell terveznie az alkalmazást a funkciók újratervezéséhez, egy lekérdezés nem támogatja az ügyféloldalon, vagy/és újra kell rendeznie az adatbázissémát, beleértve a tárolt eljárások, függvények, nézetek és triggerek definícióit. Előfordulhat, hogy a meglévő alkalmazások nem működnek titkosított oszlopokkal, ha nem tartják be az Always Encrypted korlátozásait és korlátozásait. Bár az Always Encryptedet támogató Microsoft-eszközök, termékek és szolgáltatások ökoszisztémája egyre nő, számosuk nem dolgozik titkosított oszlopokkal. Az oszlopok titkosítása a számítási feladat jellemzőitől függően hatással lehet a lekérdezési teljesítményre is.

  • Az Always Encrypted kulcsok kezelése szerepkör-elkülönítéssel, ha Az Always Encrypted használatával védi az adatokat a rosszindulatú ADATBÁZIS-okkal szemben. A szerepkörök elkülönítésével a biztonsági rendszergazda létrehozza a fizikai kulcsokat. A DBA létrehozza az oszlop főkulcsát és az oszloptitkosítási kulcs metaadat-objektumait, amelyek az adatbázisban lévő fizikai kulcsokat írják le. A folyamat során a biztonsági rendszergazdának nem kell hozzáférnie az adatbázishoz, és a DBA-nak nincs szüksége a fizikai kulcsokhoz való egyszerű szöveges hozzáférésre.

    • A részletekért tekintse meg a Kulcsok kezelése szerepkör-elkülönítéssel című cikket.

  • Az oszlop főkulcsait az Azure Key Vaultban tárolhatja a könnyű kezelés érdekében. Kerülje a Windows Tanúsítványtároló használatát (és általában az elosztott kulcstároló megoldásokat, szemben a központi kulcskezelési megoldásokkal), amelyek megnehezítik a kulcskezelést.

  • Gondolja át alaposan a több kulcs (oszlop főkulcsa vagy oszloptitkosítási kulcs) használatának kompromisszumait. A kulcskezelési költségek csökkentése érdekében tartsa kicsiben a kulcsok számát. Adatbázisonként egy oszlop főkulcsa és egy oszloptitkosítási kulcs általában elegendő állandó állapotú környezetekben (nem kulcsforgatás közepén). Szükség lehet további kulcsra, ha különböző felhasználói csoportokkal rendelkezik, amelyek mindegyike különböző kulcsokat használ, és különböző adatokhoz fér hozzá.

  • A megfelelőségi követelményeknek megfelelően forgassa el az oszlop főkulcsait. Ha oszloptitkosítási kulcsokat is el kell forgatnia, fontolja meg az online titkosítás használatát az alkalmazás állásideje minimalizálása érdekében.

  • Használjon determinisztikus titkosítást, ha az adatokon végzett számításokat (egyenlőséget) támogatni kell. Ellenkező esetben használjon véletlenszerű titkosítást. Ne használjon determinisztikus titkosítást alacsony entrópiás adatkészletekhez vagy nyilvánosan ismert eloszlású adatkészletekhez.

  • Ha aggódik amiatt, hogy harmadik felek az Ön beleegyezése nélkül jogszerűen férnek hozzá az adataihoz, győződjön meg arról, hogy minden olyan alkalmazás és eszköz, amely hozzáfér a kulcsokhoz és az adatokhoz egyszerű szövegként, a Microsoft Azure Cloudon kívül fusson. A kulcsokhoz való hozzáférés nélkül a harmadik fél nem tudja visszafejteni az adatokat, kivéve, ha megkerülik a titkosítást.

  • Az Always Encrypted nem támogatja könnyen a kulcsokhoz (és a védett adatokhoz) való ideiglenes hozzáférést. Ha például meg kell osztania a kulcsokat egy DBA-val, hogy a DBA bizonyos tisztítási műveleteket hajthasson végre a bizalmas és titkosított adatokon. A DBA-ból származó adatokhoz való hozzáférés megbízható visszavonásának egyetlen módja az oszloptitkosítási kulcsok és az adatokat védő főkulcsok elforgatása, ami költséges művelet.

  • A titkosított oszlopok egyszerű szöveges értékeinek eléréséhez a felhasználónak hozzá kell férnie az oszlopokat védő főkulcshoz (CMK), amely a CMK-t tartalmazó kulcstárolóban van konfigurálva. A felhasználónak rendelkeznie kell a VIEW ANY COLUMN MASTER KEY DEFINITION és VIEW ANY COLUMN ENCRYPTION KEY DEFINITION adatbázis engedélyekkel is.

Az alkalmazásfelhasználók bizalmas adatokhoz való hozzáférésének szabályozása titkosítással

A titkosítással biztosítható, hogy csak a titkosítási kulcsokhoz hozzáféréssel rendelkező alkalmazásfelhasználók tekinthessék meg vagy frissíthessék az adatokat.

Implementálás

  • Cellaszintű titkosítás (CLE) használata. A részletekért tekintse meg az Adatoszlop titkosítása című cikket.
  • Használja az Always Encryptedet, de vegye figyelembe a korlátozásokat. A korlátozások az alábbiakban láthatók.

Best practices:

CLE használata esetén:

  • Sql-engedélyekkel és szerepkörök használatával szabályozhatja a kulcsok elérését.

  • Az adattitkosításhoz használja az AES-t (AES 256 ajánlott). Az olyan algoritmusok, mint az RC4, a DES és a TripleDES, elavultak, és az ismert biztonsági rések miatt nem használhatók.

  • A szimmetrikus kulcsok védelme aszimmetrikus kulcsokkal/tanúsítványokkal (nem jelszavakkal) a 3DES használatának elkerülése érdekében.

  • Ügyeljen arra, hogy az adatbázist exportálással/importálással (bacpac-fájlok) cellaszintű titkosítással migrálja.

Ne feledje, hogy az Always Encrypted elsősorban az Azure SQL Database magas jogosultságú felhasználóitól (felhőszolgáltatók, DBA-k) származó bizalmas adatok védelmére szolgál– lásd: Bizalmas adatok védelme a magas jogosultságú, jogosulatlan felhasználóktól. Vegye figyelembe az alábbi kihívásokat, amikor az Always Encrypted használatával védi az adatokat az alkalmazás felhasználóitól:

  • Alapértelmezés szerint az Always Encryptedt támogató Összes Microsoft-ügyfélillesztő globális (alkalmazásonkénti) gyorsítótárat tart fenn az oszloptitkosítási kulcsok számára. Ha egy ügyfélillesztő egy egyszerű szöveges oszloptitkosítási kulcsot szerez be egy oszlop főkulcsát tartalmazó kulcstárolóval, a rendszer gyorsítótárazza az egyszerű szöveges oszloptitkosítási kulcsot. Ez megnehezíti az adatok elkülönítését egy többfelhasználós alkalmazás felhasználóitól. Ha az alkalmazás megszemélyesíti a végfelhasználókat egy kulcstároló (például az Azure Key Vault) használatakor, miután egy felhasználó lekérdezése feltölti a gyorsítótárat egy oszloptitkosítási kulccsal, egy későbbi lekérdezés, amely ugyanazt a kulcsot igényli, de egy másik felhasználó aktiválja, a gyorsítótárazott kulcsot fogja használni. Az illesztőprogram nem hívja meg a kulcstárolót, és nem ellenőrzi, hogy a második felhasználó rendelkezik-e engedéllyel az oszloptitkosítási kulcs eléréséhez. Ennek eredményeképpen a felhasználó akkor is láthatja a titkosított adatokat, ha a felhasználó nem fér hozzá a kulcsokhoz. Ha el szeretné érni a felhasználók elkülönítését egy többfelhasználós alkalmazásban, letilthatja az oszloptitkosítási kulcs gyorsítótárazását. A gyorsítótárazás letiltása további teljesítménybeli többletterhelést okoz, mivel az illesztőprogramnak minden adattitkosítási vagy visszafejtési művelethez kapcsolatba kell lépnie a kulcstárolóval.

Adatok védelme az alkalmazás felhasználói általi jogosulatlan megtekintés ellen az adatformátum megőrzése mellett

Az adatok jogosulatlan megtekintésének megakadályozására szolgáló másik módszer az adatok elrejtése vagy maszkolása az adattípusok és formátumok megőrzése mellett, hogy a felhasználói alkalmazások továbbra is kezelni tudják és megjeleníthessék az adatokat.

Implementálás

  • A dinamikus adatmaszkolással elrejtheti a táblaoszlopokat.

Megjegyzés:

Az Always Encrypted nem működik a dinamikus adatmaszkolással. Nem lehet ugyanazt az oszlopot titkosítani és maszkolni, ami azt jelenti, hogy fontossági sorrendbe kell helyeznie a használatban lévő adatok védelmét, és el kell maszkolnia az adatokat az alkalmazás felhasználói számára dinamikus adatmaszkolással.

Best practices

Megjegyzés:

A dinamikus adatmaszkolás nem használható a magas jogosultságú felhasználók adatainak védelmére. A maszkolási szabályzatok nem vonatkoznak az olyan rendszergazdai hozzáféréssel rendelkező felhasználókra, mint db_owner.

  • Ne engedélyezze az alkalmazásfelhasználóknak, hogy alkalmi lekérdezéseket futtasson (mivel előfordulhat, hogy képesek a dinamikus adatmaszkolás megkerülésére).

  • Használjon megfelelő hozzáférés-vezérlési szabályzatot (SQL-engedélyek, szerepkörök, RLS) a felhasználói engedélyek korlátozásához, hogy a maszkolt oszlopokban frissítéseket végezzenek. Ha maszkot hoz létre egy oszlopon, az nem akadályozza meg az oszlop frissítését. Azok a felhasználók, amelyek maszkolt adatokat kapnak a maszkolt oszlop lekérdezésekor, frissíthetik az adatokat, ha írási engedélyekkel rendelkeznek.

  • A dinamikus adatmaszkolás nem őrzi meg a maszkolt értékek statisztikai tulajdonságait. Ez hatással lehet a lekérdezés eredményeire (például a szűrési predikátumokat vagy illesztéseket tartalmazó lekérdezések a maszkolt adatokon).

Network security

A hálózati biztonság a hozzáférés-vezérlésre és az Ajánlott eljárásokra vonatkozik az Azure SQL Database-be való átvitel során.

Ügyfél konfigurálása biztonságos csatlakozásra az SQL Database-hez/felügyelt SQL-példányhoz

Ajánlott eljárások az Azure SQL Database-hez és a felügyelt SQL-példányhoz való csatlakozás megakadályozásához jól ismert biztonsági résekkel (például régebbi TLS-protokollok és titkosítási csomagok használatával) rendelkező ügyfélgépek és alkalmazások számára.

Implementálás

  • Győződjön meg arról, hogy az Azure SQL Database-hez és a felügyelt SQL-példányhoz csatlakozó ügyfélgépek a Legújabb Transport Layer Security (TLS) verziót használják.

Best practices

  • Minimális TLS-verzió kényszerítése az SQL Database-kiszolgáló vagy a felügyelt SQL-példány szintjén a minimális TLS-verzióbeállítással. Javasoljuk, hogy a minimális TLS-verziót állítsa 1.2-esre, miután tesztelte, hogy az alkalmazások támogatják-e. A TLS 1.2 a korábbi verziókban talált biztonsági rések javítását tartalmazza.

  • Az összes alkalmazás és eszköz konfigurálása az SQL Database-hez való csatlakozáshoz engedélyezett titkosítással

    • Titkosítás = Be, TrustServerCertificate = Ki (vagy nem Microsoft-illesztőprogramokkal egyenértékű).

  • Ha az alkalmazás olyan illesztőprogramot használ, amely nem támogatja a TLS-t, vagy támogatja a TLS régebbi verzióját, cserélje le az illesztőprogramot, ha lehetséges. Ha nem lehetséges, gondosan értékelje ki a biztonsági kockázatokat.

Támadási felület minimalizálása

Minimalizálja a rosszindulatú felhasználók által megtámadható funkciók számát. Az Azure SQL Database hálózati hozzáférési vezérlőinek implementálása.

Megemlítve: OSA-gyakorlat #5

Implementálás

Az SQL Database-ben:

  • Az Azure-szolgáltatásokhoz való hozzáférés engedélyezése kikapcsolva a kiszolgáló szintjén
  • Használjon virtuális hálózati szolgáltatásvégpontokat és virtuális hálózati tűzfalszabályokat.
  • Privát hivatkozás használata.

Felügyelt SQL-példányban:

Best practices

  • Az Azure SQL Database-hez és a felügyelt SQL-példányhoz való hozzáférés korlátozása privát végponton való csatlakozással (például privát adatelérési út használatával):

    • A felügyelt példányok a külső hozzáférés megakadályozása érdekében elkülöníthetők a virtuális hálózaton belül. Azok az alkalmazások és eszközök, amelyek ugyanabban a régióban azonos vagy társhálózatban lévő virtuális hálózatban találhatók, közvetlenül hozzáférhetnek hozzá. A különböző régióban lévő alkalmazások és eszközök használhatják a virtuális hálózatok közötti kapcsolatot vagy az ExpressRoute-kapcsolatcsoport-társviszonyt a kapcsolat létrehozásához. Az ügyfélnek hálózati biztonsági csoportokkal (NSG) kell korlátoznia a hozzáférést az 1433-as porton keresztül csak a felügyelt példányhoz hozzáférést igénylő erőforrásokhoz.
    • SQL Database esetén használja a Private Link szolgáltatást, amely dedikált privát IP-címet biztosít a virtuális hálózaton belüli kiszolgáló számára. A virtuális hálózati szolgáltatásvégpontokat virtuális hálózati tűzfalszabályokkal is használhatja a kiszolgálókhoz való hozzáférés korlátozásához.
    • A mobilfelhasználóknak pont–hely VPN-kapcsolatokkal kell csatlakozniuk az adatelérési útvonalon keresztül.
    • A helyszíni hálózatukhoz csatlakozó felhasználóknak helyek közötti VPN-kapcsolatot vagy ExpressRoute-ot kell használniuk az adatelérési útvonalon keresztüli csatlakozáshoz.

  • Az Azure SQL Database-hez és a felügyelt SQL-példányhoz úgy férhet hozzá, ha nyilvános végponthoz csatlakozik (például nyilvános adatelérési útvonal használatával). A következő ajánlott eljárásokat kell figyelembe venni:

    • Az SQL Database-beli kiszolgálók ip-tűzfalszabályokkal korlátozhatják a hozzáférést csak az engedélyezett IP-címekre.
    • Felügyelt SQL-példány esetén a hálózati biztonsági csoportok (NSG) használatával csak a szükséges erőforrásokra korlátozza a hozzáférést a 3342-s porton keresztül. További információ: Felügyelt példány biztonságos használata nyilvános végpontokkal.

    Megjegyzés:

    A felügyelt SQL-példány nyilvános végpontja alapértelmezés szerint nincs engedélyezve, és explicit módon engedélyezni kell. Ha a vállalati szabályzat nem engedélyezi a nyilvános végpontok használatát, az Azure Policy használatával megakadályozhatja a nyilvános végpontok engedélyezését.

  • Azure Networking-összetevők beállítása:

A Power BI konfigurálása az SQL Database-hez/felügyelt SQL-példányhoz való biztonságos kapcsolatokhoz

Best practices

Az App Service konfigurálása az SQL Database-hez/felügyelt SQL-példányhoz való biztonságos kapcsolatokhoz

Best practices

Azure Virtual Machine-üzemeltetés konfigurálása az SQL Database-hez/felügyelt SQL-példányhoz való biztonságos kapcsolatokhoz

Best practices

  • Az Azure-beli virtuális gépek NSG-jén az Engedélyezés és a Megtagadás szabályok kombinációjával szabályozhatja, hogy mely régiók érhetők el a virtuális gépről.

  • Győződjön meg arról, hogy a virtuális gép a cikk szerint van konfigurálva, az Azure-beli IaaS számítási feladatok biztonsági ajánlott eljárásai.

  • Győződjön meg arról, hogy az összes virtuális gép egy adott virtuális hálózathoz és alhálózathoz van társítva.

  • A kényszerített bújtatásra vonatkozó útmutató alapján értékelje ki, hogy szüksége van-e az alapértelmezett 0.0.0.0/internet útvonalra.

    • Ha igen – például előtérbeli alhálózat – akkor tartsa meg az alapértelmezett útvonalat.
    • Ha nem – például középső réteg vagy háttérbeli alhálózat – akkor engedélyezze a kényszerített bújtatást, hogy a forgalom az interneten keresztül ne érje el a helyszíni (más néven helyszíni) forgalmat.

  • A nem kötelező alapértelmezett útvonalak implementálása társviszony-létesítés vagy helyszíni csatlakozás esetén.

  • Felhasználói útvonalak implementálása, ha csomagvizsgálat céljából a virtuális hálózat összes forgalmát egy hálózati virtuális berendezésnek kell elküldenie.

  • Virtuális hálózati szolgáltatásvégpontok használata a PaaS-szolgáltatásokhoz, például az Azure Storage-hoz való biztonságos hozzáféréshez az Azure gerinchálózatán keresztül.

Védelem az elosztott szolgáltatásmegtagadási (DDoS) támadások ellen

Az elosztott szolgáltatásmegtagadási (DDoS) támadásokat rosszindulatú felhasználók kísérlik meg a hálózati forgalom elárasztását küldeni az Azure SQL Database-be azzal a céllal, hogy túlterheljék az Azure-infrastruktúrát, és emiatt elutasítsák az érvényes bejelentkezéseket és számítási feladatokat.

Megemlítve: OSA-gyakorlat #9

Implementálás

A DDoS-védelem automatikusan engedélyezve van az Azure Platform részeként. Ez magában foglalja a folyamatos forgalomfigyelést és a nyilvános végpontok hálózati szintű támadásainak valós idejű mérséklését.

Best practices

  • Kövesse a Támadási felület minimalizálása című cikkben leírt eljárásokat, amelyek segítenek minimalizálni a DDoS-támadási fenyegetéseket.

  • Az Advanced Threat Protection Brute force SQL hitelesítő adatokra vonatkozó riasztása segít észlelni a találgatásos támadásokat. Bizonyos esetekben a riasztás még a behatolástesztelési számítási feladatokat is megkülönbözteti.

  • Az SQL Database-hez csatlakozó Azure-beli virtuális gépek üzemeltetési alkalmazásai esetén:

    • Kövesse a Felhőhöz készült Microsoft Defender internetkapcsolattal rendelkező végpontokon keresztüli hozzáférés korlátozására vonatkozó javaslatot.
    • Virtuálisgép-méretezési csoportok használatával futtathatja az alkalmazás több példányát Azure-beli virtuális gépeken.
    • Tiltsa le az RDP-t és az SSH-t az internetről a találgatásos támadás megakadályozása érdekében.

Monitorozás és naplózás

Ez a szakasz olyan képességekre hivatkozik, amelyek segítenek észlelni az adatbázisok elérésére vagy kihasználására tett szokatlan és potenciálisan káros kísérleteket jelző rendellenes tevékenységeket. Emellett az adatbázis-naplózás beállításának ajánlott eljárásait is ismerteti az adatbázis-események nyomon követésére és rögzítésére.

Adatbázisok védelme a támadások ellen

A komplex veszélyforrások elleni védelem lehetővé teszi a potenciális fenyegetések észlelését és elhárítását a rendellenes tevékenységekre vonatkozó biztonsági riasztások biztosításával.

Implementálás

  • Az Advanced Threat Protection for SQL használatával észlelheti az adatbázisok elérésére vagy kihasználására tett szokatlan és potenciálisan káros kísérleteket, többek között a következőket:
    • SQL-injektálási támadás.
    • Hitelesítő adatok ellopva/kiszivárogva.
    • Jogosultsági visszaélés.
    • Adatkiszivárgás.

Best practices

  • Konfigurálja a Microsoft Defendert az SQL-hez egy adott kiszolgálóhoz vagy felügyelt példányhoz. Konfigurálhatja a Microsoft Defendert az SQL-hez az előfizetés összes kiszolgálója és felügyelt példánya számára a Felhőhöz készült Microsoft Defender engedélyezésével.

  • A teljes körű vizsgálathoz ajánlott engedélyezni az SQL Database naplózását. A naplózással nyomon követheti az adatbázis-eseményeket, és megírhatja őket egy auditnaplóba egy Azure Storage-fiókban vagy az Azure Log Analytics-munkaterületen.

Kritikus biztonsági események naplózása

Az adatbázis-események nyomon követése segít megérteni az adatbázis-tevékenységeket. Betekintést nyerhet az olyan eltérésekbe és anomáliákba, amelyek üzleti aggodalmakat vagy feltételezett biztonsági szabálysértéseket jelezhetnek. Emellett lehetővé teszi és megkönnyíti a megfelelőségi szabványok betartását.

Implementálás

  • Engedélyezze az SQL Database naplózását vagy a felügyelt példányok naplózását az adatbázis-események nyomon követéséhez és az Azure Storage-fiók, a Log Analytics-munkaterület (előzetes verzió) vagy az Event Hubs (előzetes verzió) naplózási naplójába való írásához.

  • Az auditnaplók írhatók Azure Storage-fiókba, Egy Log Analytics-munkaterületre az Azure Monitor-naplók általi felhasználás céljából, vagy az eseményközpont használatával történő felhasználás céljából az eseményközpontba. A beállítások bármilyen kombinációját konfigurálhatja, és a naplók mindegyikéhez meg lesznek írva.

Best practices

  • Ha konfigurálja az SQL Database-naplózást a kiszolgálón vagy a felügyelt példány naplózását események naplózására, a rendszer az adott kiszolgálón lévő összes meglévő és újonnan létrehozott adatbázist naplózni fogja.
  • Alapértelmezés szerint a naplózási szabályzat tartalmazza az adatbázisokon végzett összes műveletet (lekérdezéseket, tárolt eljárásokat és sikeres és sikertelen bejelentkezéseket), ami nagy mennyiségű naplót eredményezhet. Javasoljuk az ügyfeleknek, hogy a PowerShell használatával konfigurálják a naplózást különböző típusú műveletekhez és műveletcsoportokhoz. Ennek konfigurálása segít szabályozni a naplózott műveletek számát, és minimalizálni az eseményvesztés kockázatát. Az egyéni naplózási konfigurációk lehetővé teszik, hogy az ügyfelek csak a szükséges naplózási adatokat rögzítsék.
  • Az auditnaplók közvetlenül az Azure Portalon vagy a konfigurált tárolóhelyen használhatók.

Megjegyzés:

A Log Analytics naplózásának engedélyezése a betöltési arányok alapján költségekkel jár. Vegye figyelembe a beállítással járó költségeket, vagy fontolja meg az auditnaplók Azure-tárfiókban való tárolását.

További források

Biztonságos naplózási naplók

A tárfiókhoz való hozzáférés korlátozása a vámok elkülönítésének támogatása és a DBA és az auditorok elkülönítése érdekében.

Implementálás

  • Ha naplókat ment az Azure Storage-ba, győződjön meg arról, hogy a tárfiókhoz való hozzáférés a minimális biztonsági alapelvekre korlátozódik. Szabályozhatja, hogy kinek van hozzáférése a tárfiókhoz.
  • További információ: Az Azure Storage-hozzáférés engedélyezése.

Best practices

  • A naplózási célhoz való hozzáférés szabályozása kulcsfontosságú fogalom a DBA auditoroktól való elválasztásához.

  • A bizalmas adatokhoz való hozzáférés naplózása során fontolja meg az adatok adattitkosítással történő védelmét, hogy elkerülje az adatszivárgást az Auditor számára. További információ: Bizalmas adatok védelme a magas jogosultságú, jogosulatlan felhasználóktól.

Biztonságkezelés

Ez a szakasz az adatbázisok biztonsági helyzetének kezelésével kapcsolatos különböző szempontokat és ajánlott eljárásokat ismerteti. Ajánlott eljárásokat tartalmaz annak biztosítására, hogy az adatbázisok a biztonsági szabványoknak megfelelően legyenek konfigurálva, felderítsék és osztályozzák és nyomon követhessék a potenciálisan bizalmas adatokhoz való hozzáférést az adatbázisokban.

Győződjön meg arról, hogy az adatbázisok úgy vannak konfigurálva, hogy megfeleljenek a biztonsági ajánlott eljárásoknak

Proaktívan javíthatja az adatbázis biztonságát a lehetséges adatbázis-biztonsági rések felderítésével és javításával.

Implementálás

  • Engedélyezze az SQL Sebezhetőségi felmérés (VA) használatát, hogy biztonsági problémákat keressen az adatbázisban, és automatikusan fusson rendszeresen az adatbázisokon.

Best practices

  • Először futtassa a VA-t az adatbázisokon, és iterálja a biztonsági ajánlott eljárásokat ellenző sikertelen ellenőrzések szervizelésével. Állítsa be az elfogadható konfigurációk alapkonfigurációit, amíg a vizsgálat tiszta nem lesz, vagy az összes ellenőrzés sikeres.

  • Rendszeres ismétlődő vizsgálatokat konfigurálhat heti egyszeri futtatásra, és konfigurálhatja az érintett személyt az összefoglaló e-mailek fogadására.

  • Minden heti vizsgálat után tekintse át a VA összegzését. A talált biztonsági rések esetén értékelje ki az előző vizsgálati eredménytől való eltérést, és állapítsa meg, hogy meg kell-e oldani az ellenőrzést. Ellenőrizze, hogy van-e jogos oka a konfiguráció módosításának.

  • Szükség esetén feloldhatja az ellenőrzések és az alaptervek frissítését. Hozzon létre jegyelemeket a műveletek feloldásához, és kövesse nyomon ezeket a feloldásukig.

További források

Bizalmas adatok azonosítása és címkézése

Felderítheti azokat az oszlopokat, amelyek bizalmas adatokat tartalmazhatnak. A bizalmas adatok nagyban függnek az ügyféltől, a megfelelőségi szabályozástól stb., és az adatokért felelős felhasználóknak kell kiértékelni őket. Sorolja be az oszlopokat speciális bizalmassági alapú naplózási és védelmi forgatókönyvek használatára.

Implementálás

  • Az SQL Data Discovery és -besorolás használatával felderítheti, osztályozhatja, címkézheti és védheti az adatbázisokban lévő bizalmas adatokat.
    • Tekintse meg az automatizált felderítés által létrehozott besorolási javaslatokat az SQL Data Discovery és a Besorolás irányítópulton. Fogadja el a megfelelő besorolásokat, hogy a bizalmas adatok tartósan besorolási címkékkel legyen megjelölve.
    • Az automatikus mechanizmus által nem felderített további bizalmas adatmezők besorolásának manuális hozzáadása.
  • További információ: SQL Data Discovery and Classification.

Best practices

  • Rendszeresen monitorozza a besorolási irányítópultot az adatbázis besorolási állapotának pontos értékelése érdekében. Az adatbázis-besorolási állapotról készült jelentést megfelelőségi és naplózási célból exportálhatja vagy kinyomtathatja megosztásra.

  • Folyamatosan monitorozza a javasolt bizalmas adatok állapotát az SQL sebezhetőségi felmérésében. Kövesse nyomon a bizalmas adatfelderítési szabályt, és azonosítsa a besoroláshoz ajánlott oszlopok eltérését.

  • A besorolást a szervezet adott igényeihez igazodva használhatja. Szabja testre az Information Protection-szabályzatot (bizalmassági címkék, információtípusok, felderítési logika) az SQL Information Protection-szabályzatban a Felhőhöz készült Microsoft Defender.

Bizalmas adatokhoz való hozzáférés nyomon követése

Figyelje meg, hogy ki fér hozzá a bizalmas adatokhoz, és rögzítse a bizalmas adatokra vonatkozó lekérdezéseket az auditnaplókban.

Implementálás

Best practices

A biztonság és a megfelelőség állapotának megjelenítése

Használjon egységes infrastruktúrabiztonsági felügyeleti rendszert, amely erősíti az adatközpontok biztonsági pozícióját (beleértve az SQL Database adatbázisait is). Tekintse meg az adatbázisok biztonságával és megfelelőségi állapotával kapcsolatos javaslatok listáját.

Implementálás

Gyakori biztonsági fenyegetések és lehetséges kockázatcsökkentések

Ez a szakasz segítséget nyújt bizonyos támadási vektorok elleni védelemmel kapcsolatos biztonsági intézkedések megtalálásában. A legtöbb kockázatcsökkentés a fenti biztonsági irányelvek egy vagy több követésével érhető el.

Biztonsági fenyegetés: Adatkiszivárgás

Az adatkiszivárgás az adatok jogosulatlan másolása, átvitele vagy lekérése egy számítógépről vagy kiszolgálóról. Lásd a Wikipédiában az adatkiszivárgás definícióját .

Csatlakozás kiszolgálóra nyilvános végponton keresztül adatkiszivárgási kockázatot jelent, mivel az ügyfeleknek meg kell nyitniuk a tűzfalaikat a nyilvános IP-címeken.

1. forgatókönyv: Egy Azure-beli virtuális gépen lévő alkalmazás egy Azure SQL Database-adatbázishoz csatlakozik. Egy gazember hozzáfér a virtuális géphez, és feltöri azt. Ebben az esetben az adatkiszivárgás azt jelenti, hogy egy, a zsivány virtuális gépet használó külső entitás csatlakozik az adatbázishoz, átmásolja a személyes adatokat, és egy blobtárolóban vagy egy másik SQL Database-ben tárolja azokat egy másik előfizetésben.

2. forgatókönyv: Egy gazember DBA. Ezt a forgatókönyvet gyakran a szabályozott iparágak biztonsági szempontból érzékeny ügyfelei vetik fel. Ebben az esetben egy magas jogosultságú felhasználó adatokat másolhat az Azure SQL Database-ből egy másik, az adattulajdonos által nem felügyelt előfizetésbe.

Lehetséges kockázatcsökkentések

Az Azure SQL Database és a felügyelt SQL-példány ma a következő technikákat kínálja az adatkiszivárgási fenyegetések enyhítésére:

  • Az Azure-beli virtuális gépek NSG-jén az Engedélyezés és a Megtagadás szabályok kombinációjával szabályozhatja, hogy mely régiók érhetők el a virtuális gépről.
  • Ha kiszolgálót használ az SQL Database-ben, adja meg a következő beállításokat:
    • Engedélyezze az Azure Services kikapcsolását.
    • Csak az Azure-beli virtuális gépet tartalmazó alhálózatról engedélyezze a forgalmat egy virtuális hálózati tűzfalszabály beállításával.
    • Privát hivatkozás használata
  • Felügyelt SQL-példány esetén a magánhálózati IP-hozzáférés alapértelmezés szerint történő használata a gazember virtuális gép első adatkiszivárgási aggályát adja meg. Kapcsolja be az alhálózat-delegálási funkciót egy alhálózaton, hogy automatikusan beállítsa a legkorlátozóbb szabályzatot egy felügyelt SQL-példány alhálózatán.
  • A rogue DBA-probléma jobban ki van téve a felügyelt SQL-példánynak, mivel nagyobb felülettel rendelkezik, és a hálózati követelmények láthatók az ügyfelek számára. Ehhez a legjobb megoldás az ebben a biztonsági útmutatóban szereplő összes gyakorlat alkalmazása a Rogue DBA-forgatókönyv megelőzésére (nem csak az adatkiszivárgás esetén). Az Always Encrypted az egyik módszer a bizalmas adatok védelmére azáltal, hogy titkosítja őket, és a kulcs nem érhető el a DBA számára.

Az üzletmenet folytonosságának és rendelkezésre állásának biztonsági szempontjai

A legtöbb biztonsági szabvány a működés folytonossága szempontjából kezeli az adatok rendelkezésre állását, amelyet a redundancia és a feladatátvételi képességek implementálásával érhet el az egyes meghibásodási pontok elkerülése érdekében. Vészforgatókönyvek esetén gyakori eljárás az adatok és naplófájlok biztonsági mentésének megtartása. Az alábbi szakasz magas szintű áttekintést nyújt az Azure-ba beépített képességekről. Emellett további lehetőségeket is biztosít, amelyek konfigurálhatók az adott igények kielégítésére:

További lépések