Az adatvédelem áttekintése

Azure DevOps Services

Az Azure DevOps Services egy felhőalapú alkalmazás a fejlesztési projektekhez a tervezéstől az üzembe helyezésig. A helyszíni képességek alapján további felhőszolgáltatásokkal felügyeljük a forráskódot, a munkaelemeket, a buildeket és a teszteket. Az Azure DevOps szolgáltatásként nyújtott platform (PaaS) infrastruktúrát és számos Azure-szolgáltatást használ, köztük Azure SQL, hogy megbízható, globálisan elérhető szolgáltatást nyújtson fejlesztési projektjeihez.

Ez a cikk a Microsoft által a projektek biztonságának, rendelkezésre állásának, biztonságának és magánhálózatának megőrzéséhez szükséges lépéseket ismerteti. Emellett azt is ismerteti, hogy milyen szerepet játszik a projektek biztonságának megőrzésében.

Ez a cikk olyan szervezeti rendszergazdáknak és informatikai szakembereknek szól, akik naponta kezelik a projekteszközöket. Ez az azure devops-t már jól ismerő és a Microsoft által az Azure DevOpsban tárolt adategységek védelmével kapcsolatos további információkra kíváncsi felhasználók számára lesz a leg hasznosabb.

Elkötelezettségünk

A Microsoft segít biztosítani, hogy projektjei kivétel nélkül biztonságosak és biztonságosak maradjanak. Az Azure DevOpsban tárolt projektek többrétegű biztonsági és irányítási technológiák, üzemeltetési eljárások és megfelelőségi szabályzatok előnyeit élvezhetik. Adatvédelmet és adatintegritást érvényesítünk inaktív állapotban és átvitel közben is.

A fenyegetések négy alapvető kategóriába sorolhatók: az adatok rendelkezésre állása, a szolgáltatások rendelkezésre állása, a szolgáltatásbiztonság és az adatvédelem. Ez a cikk az egyes kategóriákon belüli konkrét fenyegetéseket ismerteti, és ismerteti, hogy az Azure DevOps mit tesz azok elhárításához. A cikk először ismerteti az adatok tárolásának módját, valamint azt, hogy az Azure DevOps hogyan kezeli az adatokhoz való hozzáférést.

Az adatvédelemhez a rendszergazdák és a felhasználók aktív bevonása szükséges, akiknek tudniuk kell, hogy milyen lépéseket kell tenni az objektumok jogosulatlan nyilvánosságra hozatala és illetéktelen módosítása elleni védelme érdekében. Legyen explicit, amikor engedélyeket ad a felhasználói hozzáférési pontoknak, így csak a megfelelő személyek férnek hozzá az Adatokhoz az Azure DevOpsban.

Bármi legyen is a megközelítése, minden adatot potenciálisan "veszélynek" kell tekintenie, függetlenül attól, hogy hol van, vagy hogyan használják. Ez a felhőbeli és a privát adatközpontban tárolt adatokra egyaránt igaz. Fontos, hogy osztályozza az adatokat, azok érzékenységét és kockázatát, valamint azt, hogy milyen kárt okozhat, ha illetéktelenül sérülnek. Emellett kategorizálja az adatokat egy általános információbiztonsági felügyeleti szabályzathoz viszonyítva.

Az Azure-ra épül

Az Azure DevOps magas szintű architektúrájának ábrája.

Az Azure DevOpsot teljes egészében Azure-adatközpontokban üzemeltetjük. Az Azure DevOps számos alapvető Azure-szolgáltatást használ, beleértve a számítást, a tárolást, a hálózatkezelést, a Azure SQL, az identitás- és hozzáférés-kezelést, valamint a Azure Service Bus.

Az Azure DevOps az Azure Storage-ot használja a szolgáltatás metaadatainak és az ügyfelek adatainak elsődleges adattáraként. Az adatok típusától, valamint a tárolási és a lekérési igényektől függően az Azure DevOps az adattároláshoz az Azure Blob Storage-ot (nagyméretű bináris objektumokhoz) és az Azure SQL-t használja. Az Azure DevOps-szolgáltatások adatvédelemmel kapcsolatos megközelítésének megértéséhez fontos ismerni ezeket az elemeket.

  • Azure Blob Storage strukturálatlan adatok nagy darabjait tárolja. Minden projekt az Azure Blob Storage szolgáltatást használja. Az adatok bizalmas vagy személyes adatokat is tartalmaznak, például a forrásfájlok tartalmát és a munkaelemekhez használt mellékleteket. A legtöbb projekt esetében a használatban lévő tárolók többsége ilyen strukturálatlan blobtároló. További információ: Azure Blob Storage.

  • Azure SQL Database Storage tárolja a szervezet strukturált és tranzakciós aspektusait, beleértve a projekt metaadatait, a verziószámozott verziókövetési előzményeket és a munkaelemek részleteit. Az adatbázis-tároló gyors hozzáférést biztosít a projekt fontos elemeihez, és indexeket biztosít a blobtárolóban a fájlok és mellékletek kereséséhez. További információ: Azure SQL Database.

A rendszergazdák a felhasználói identitásokra vagy csoportokra vonatkozó engedélyek megadásával vagy korlátozásával kezelhetik az erőforrásokhoz való hozzáférést. Az Azure DevOps a felhasználói identitások összevont hitelesítését használja Az Azure Active Directory (Azure AD) és a Microsoft-fiókok használatával.

A hitelesítés során a rendszer átirányítja a felhasználót a hitelesítésszolgáltatóhoz, ahol megadja a hitelesítő adatait. Miután a hitelesítési szolgáltató ellenőrizte a felhasználó hitelesítő adatait, az Azure DevOps kiad egy hitelesítési cookie-t a felhasználónak, amely lehetővé teszi a felhasználó számára, hogy hitelesítve maradjon az Azure DevOpsban.

Így a felhasználó hitelesítő adatai soha nem lesznek közvetlenül megosztva az Azure DevOpsszal. Minden olyan Azure DevOps-erőforrás esetében, amelyhez a felhasználó megpróbál hozzáférni, a rendszer a felhasználó explicit engedélyei, valamint a csoporttagságon keresztül örökölt engedélyek alapján érvényesíti az engedélyeket. A rendszergazdák hozzáférés-vezérléssel védhetik a szervezethez, a projektgyűjteményekhez, a csapatprojektekhez, valamint a csapatra vonatkozó adatokhoz és funkciókhoz való hozzáférést. A rendszergazdák konkrétabb eszközöket is védhetnek, például verziókövetési mappákat és munkaelemek területelérési utakat.

Adatok rendelkezésre állása

Az Azure DevOps számos Azure Storage-funkciót használ az adatok rendelkezésre állásának biztosítására hardverhiba, szolgáltatáskimaradás vagy régiós katasztrófa esetén. Emellett az Azure DevOps csapata eljárásokat követve védi az adatokat a véletlen vagy rosszindulatú törléstől.

Adatredundancia

Az adatok hardver- vagy szolgáltatáshibák esetén történő védelme érdekében az Azure Storage georeplikálást biztosít az ügyféladatok két régió között, ugyanabban a földrajzi helyen. Az Azure például georeplikálást végezhet Észak- és Nyugat-Európa, illetve észak- és déli Egyesült Államok között.

Az Azure Blob Storage esetében az ügyféladatok háromszor replikálódnak egy adott régióban, és aszinkron módon replikálódnak egy második régióba ugyanazon a földrajzi helyen. Így az Azure mindig az adatok hat példányának megfelelőt tartja fenn. Ez lehetővé teszi a feladatátvételt egy külön régióba, ha jelentős kimaradás vagy katasztrófa történik, miközben helyi redundanciát biztosít a régión belüli hardverhibákra. Az Azure SQL Database Storage esetében a napi biztonsági mentések a helyszínen kívül maradnak, ha regionális katasztrófa történik.

Megjegyzés

Az adatredundancia és a feladatátvétel tekintetében:

  • Ez egy percek alatt mért eltérés, amikor a Microsoft replikálja az adatokat az elsődleges és a másodlagos régió között.
  • A másodlagos régióba történő feladatátvételt a Microsoftnak központilag kell eldöntenie, mivel az az érintett skálázási egység összes ügyfelet érinti. Szélsőséges körülmények kivételével a Microsoft úgy dönt, hogy nem veszi át a feladatátvételt, hogy az ügyféladatok ne vesszenek el.
  • Az Azure DevOps 99,9%-os üzemidejű SLA-garanciát kínál, és a havi díjak egy részét visszatéríti, ha az adott hónapban elmulasztotta az SLA-t.
  • Mivel Brazíliában csak egy régió van, a rendszer az USA déli középső régiójába replikálja az ügyféladatokat vészhelyreállítási célokból.

Hibák történnek

Az adatok véletlen törlése elleni védelem érdekében a Microsoft a Azure Blob Storage-ben lévő blobok és az Azure SQL Database adatbázisainak időponthoz kötött biztonsági mentését is elvégzi. Az összes blobnak külön példánya van, és a módosítások hozzá lesznek fűzve az egyes tárfiókokhoz. Mivel ezek az adatok nem módosíthatók, a biztonsági mentési eljárások részeként nem kell átírnia a meglévő tárolót.

A biztonsági másolatok a Azure SQL Database standard részei, és az Azure DevOps ezt használja. 28 napnyi adatot őrizünk meg. Mindkét esetben ezek a biztonsági másolatok egy párosított régióban is replikálódnak, így biztosítható, hogy helyreálljon egy regionális szolgáltatáskimaradás.

További védelem, hogy az ügyfelek a törlést követő 28 napig helyreállíthatják törölt szervezeteiket vagy projektjeiket. A törölt szervezetek és projektek 28 napig "helyreállítható módon törölt" fázisban vannak, így az ügyfelek igény szerint helyreállnak. 28 nap elteltével végleg törlődnek, és nem állíthatók vissza.

Fontos

A véletlen törlés itt olyan forgatókönyvekre utal, amelyek a szolgáltatásainkban bekövetkező incidens következtében merülnek fel, és nem tartalmazzák az eszközök (például adattárak, munkaelemek, mellékletek, összetevők) ügyfelek általi véletlen törlését. Nem támogatjuk az ügyfelek által véletlenül törölt objektumok visszaállítását, mivel ezek a biztonsági másolatok az üzletmenet folytonosságát és csak a kimaradásokból vagy vészhelyzetekből való helyreállítást segítik elő.

A gyakorlat kritikus fontosságú

Az adatok több redundáns biztonsági mentése jó megoldás, de gyakorlás nélkül a visszaállítás kiszámíthatatlan lehet. Azt mondták, hogy "a biztonsági mentések soha nem hiúsulnak meg, a visszaállítások igen." Bár technikailag helytelen, a vélemény helyes.

A Microsoft rendszeresen gyakorolja a különböző adathalmazok biztonsági mentésből való visszaállítását. Az Azure-ból származó georedundáns tárolást rendszeresen tesztelik. Emellett időről időre visszaállítjuk a biztonsági másolatokat, hogy helyreállítsuk az emberi hibákat, például amikor egy ügyfél véletlenül törölt egy projektet az Azure DevOpsban. A katasztrófa- és adatsérülési forgatókönyvek számos kombinációja létezik, amelyeket továbbra is rendszeresen tervezünk és futtatunk.

Szolgáltatás rendelkezésre állása

Az Azure DevOps elosztott szolgáltatásmegtagadási (DDoS)-védelmet és élő webhelyválaszt kínál, így biztosíthatja, hogy hozzáférhessen a szervezethez és a kapcsolódó eszközökhöz.

DDoS-védelem

Bizonyos esetekben egy rosszindulatú DDoS-támadás befolyásolhatja a szolgáltatás rendelkezésre állását. Az Azure rendelkezik egy DDoS védelmi rendszerrel, amely segít megelőzni a szolgáltatásunk elleni támadásokat. Olyan szabványos észlelési és kockázatcsökkentési technikákat használ, mint a SYN-cookie-k, a sebességkorlátozás és a kapcsolati korlátok. A rendszer úgy lett kialakítva, hogy ne csak kívülről, hanem az Azure-on belülről is ellenálljon a támadásoknak.

Az Azure Védelmi rendszereken áthatoló alkalmazásspecifikus támadások esetén az Azure DevOps alkalmazás- és szervezetszintű kvótákat és szabályozást hoz létre. Ez segít megelőzni a kulcsfontosságú szolgáltatási erőforrások túlzott használatát támadás vagy az erőforrások véletlen helytelen használata során.

Élő webhely válasza

Ritka esetekben előfordulhat, hogy élő webhelyre kell reagálnia a szolgáltatás rendelkezésre állásával kapcsolatos problémára. A probléma gyors azonosításához és a fejlesztői csapat szükséges erőforrásainak bevonásához rendelkezésre áll egy üzemeltetési csapat. Ezek az erőforrások ezután megoldják a problémát. Emellett a szolgáltatás állapotlapjának frissítésére is törekednek a szolgáltatást érintő probléma észlelését követő néhány percen belül. Miután a csapat megoldott egy problémát, azonosítják a probléma kiváltó okát, és nyomon követik a szükséges módosításokat, hogy a jövőben megelőzzék a hasonló problémákat.

Az Azure DevOps élő webhelykezelési folyamatai a felhasználói élményre és a szolgáltatás állapotára összpontosítanak. Ezek a folyamatok minimálisra csökkentik a problémák észlelésére, megválaszolására és enyhítésére vonatkozó időt. Minden mérnöki tudományág érintett és felelős, ezért a közvetlen tapasztalatból folyamatosan fejlődnek. Ez azt jelenti, hogy a monitorozási, diagnosztikai, rugalmassági és minőségbiztosítási folyamatok idővel javulnak.

Az Azure DevOps élő webhelykezelésének három különböző nyomvonala van: telemetriai adatok, incidenskezelés és élő webhelyek áttekintése. Ezek a számok a következők:

Az Azure DevOps Services élő webhelykezelési folyamatának képe.

Az üzemeltetési csapat az egyes szervezetek rendelkezésre állási metrikáit is figyeli. Ezek a metrikák olyan konkrét feltételekre nyújtanak betekintést, amelyek csak néhány ügyfelet érinthetnek. Az adatok vizsgálata gyakran célzott fejlesztéseket eredményezhet az ügyfélspecifikus problémák megoldásához. Bizonyos esetekben a Microsoft akár közvetlenül is kapcsolatba léphet Önnel, hogy megértse a felhasználói élményét, és önnel együttműködve javítsa a szolgáltatást.

A Microsoft szolgáltatói szerződést (SLA) tesz közzé, és pénzügyi garanciát nyújt annak biztosítására, hogy minden hónapban eleget teszünk ennek a szerződésnek. További információkért lásd az Azure DevOps SLA-ját.

Előfordulhat, hogy a partnercsapatoknak vagy függőségeknek olyan incidensei vannak, amelyek hatással vannak az Azure DevOpsra. A partnercsapatok hasonló megközelítéseket követnek a szolgáltatáskimaradások azonosításához, megoldásához és az azokból való tanuláshoz.

Szolgáltatásbiztonság

A szolgáltatásbiztonság folyamatos éberséget igényel, a megfelelő tervezési és kódolási technikáktól a működési tényezőkig. A Microsoft aktívan fektet be a biztonsági rések megelőzésébe és a behatolásészlelésbe. Biztonsági incidens esetén a Microsoft biztonsági választervekkel minimalizálja az adatszivárgást, az adatvesztést vagy a sérülést. További információ: Tudnivalók a biztonságról, a hitelesítésről és az engedélyezésről.

Biztonság kialakítás szerint

Az Azure DevOps biztonságos. Az Azure DevOps a Microsoft biztonsági fejlesztési életciklusát használja a fejlesztési folyamat középpontjában. A Microsoft Operational Security Assurance program végigvezeti a felhőműveleti eljárásain. Az alábbi módszerek a következő követelményeket határozzák meg:

  • Fenyegetésmodellezés a szolgáltatás tervezése során.
  • Kövesse a tervezéssel és a kóddal kapcsolatos ajánlott eljárásokat.
  • A biztonság ellenőrzése standard eszközökkel és teszteléssel.
  • A működési és ügyféladatokhoz való hozzáférés korlátozása.
  • Az új funkciók bevezetésének egy merev jóváhagyási folyamaton keresztül történő bevezetése.

Az Azure DevOps csapata éves képzési követelményekkel rendelkezik az összes mérnök és üzemeltetési munkatárs számára, és szponzorálja a Microsoft mérnökei által tartott informális "barna zsákos" találkozókat. Miután megoldottak egy barna zsákos értekezleten felmerült problémát, megosztják a tanultakat a csapat többi tagjával.

A felhőszolgáltatás csak annyira biztonságos, mint a gazdaplatform. Az Azure DevOps az infrastruktúra nagy részén a PaaS-t használja. A PaaS automatikusan rendszeres frissítéseket biztosít az ismert biztonsági résekhez. Az Azure-ban üzemeltetett virtuális gépek szolgáltatott infrastruktúrát (IaaS) használnak, például egy üzemeltetett buildszolgáltatáshoz. Az ilyen rendszerképek rendszeres frissítéseket kapnak, hogy tartalmazzák az Windows Update által elérhető legújabb biztonsági javításokat. Ugyanez a frissítési szigorúság vonatkozik a helyszíni gépekre, beleértve az üzembe helyezéshez, monitorozáshoz és jelentéskészítéshez használtakat is.

Az Azure DevOps csapata rendszeres, biztonságközpontú behatolási tesztelést végez az Azure DevOpsban. Ugyanazokat a technikákat és mechanizmusokat használja, mint a rosszindulatú támadók, a behatolási tesztek megpróbálják kihasználni az Azure DevOps élő éles szolgáltatásait és infrastruktúráját. A cél a valós biztonsági rések, konfigurációk, hibák vagy más biztonsági rések azonosítása egy szabályozott folyamat során. A csapat áttekinti az eredményeket, hogy azonosítsa a fejlesztés egyéb területeit, és növelje a megelőző rendszerek és a képzés minőségét. A Szolgáltatásmegbízhatósági portálon áttekintheti az Azure DevOps legutóbbi behatolási tesztjeinek eredményeit.

Hitelesítő adatok biztonsága

Az Azure DevOpsban tárolt hitelesítő adatai iparági ajánlott eljárások szerint vannak tárolva. További információ a hitelesítő adatok tárolásáról.

Biztonsági problémák jelentése

Ha a behatolásteszt során úgy véli, hogy az Azure DevOps szolgáltatással kapcsolatos potenciális biztonsági hibát észlelt, 24 órán belül jelentse a Microsoftnak. További információ: A számítógép biztonsági résének jelentése.

Fontos

Bár a behatolástesztelési tevékenységekről már nincs szükség a Microsoft értesítésére, továbbra is meg kell felelnie a Microsoft Cloud egyesített behatolástesztelési szabályainak.

Bounty program

Az Azure DevOps részt vesz a Microsoft Online Services Bounty Programban. Ez a program jutalmazza azokat a biztonsági kutatókat, akik problémákat jelentenek számunkra, és további személyeket ösztönöz az Azure DevOps biztonságának megőrzésére. További információ: Azure DevOps Bounty Program.

Hozzáférés korlátozása

A Microsoft szigorúan ellenőrzi, hogy ki férhet hozzá az éles környezethez és az ügyféladatokhoz. A hozzáférés a minimálisan szükséges jogosultsági szinten, és csak a megfelelő indoklások megadása és ellenőrzése után lesz megadva. Ha egy csapattagnak hozzáférésre van szüksége egy sürgős probléma megoldásához vagy egy konfigurációs módosítás üzembe helyezéséhez, akkor "igény szerinti" hozzáférést kell kérnie az éles szolgáltatáshoz. A hozzáférés a probléma megoldása után azonnal megszűnik.

A hozzáférési kérelmeket és jóváhagyásokat egy külön rendszerben követik nyomon és figyelik. A rendszer minden hozzáférése összefügg ezekkel a jóváhagyásokkal, és ha nem jóváhagyott hozzáférést észlelünk, az üzemeltetési csapat riasztást kap a vizsgálathoz.

Minden távoli rendszer-hozzáféréshez kétfaktoros hitelesítést használunk. Tehát ha az egyik fejlesztőnk vagy üzemeltetési munkatársunk felhasználónevét és jelszavát ellopták, az adatok védettek maradnak. Ez azt jelenti, hogy a szolgáltatáshoz való távoli hozzáférés engedélyezése előtt további hitelesítést kell végezni intelligens kártyán vagy előre jóváhagyott telefonszámra irányuló telefonhívással.

Emellett a Microsoft titkos kódokat használ a szolgáltatás kezeléséhez és karbantartásához, például RDP-jelszavakat, SSL-tanúsítványokat és titkosítási kulcsokat. Ezek mindegyike biztonságosan kezelhető, tárolható és továbbítható a Azure Portal keresztül. A titkos kódokhoz való hozzáféréshez külön engedély szükséges, amelyet a rendszer biztonságos módon naplóz és rögzít. A titkos kulcsok rendszeres időközönként rotáltak, és biztonsági esemény esetén igény szerint elforgathatók.

Az Azure DevOps üzemeltetési csapata rögzített rendszergazdai munkaállomásokat használ a szolgáltatás kezeléséhez. Ezek a gépek minimális számú alkalmazást futtatnak, és logikailag szegmentált környezetben működnek. Az üzemeltetési csapat tagjainak kétfaktoros hitelesítéssel kell megadniuk bizonyos hitelesítő adatokat a munkaállomások eléréséhez. A rendszer minden hozzáférést figyel és biztonságosan naplóz. A szolgáltatás külső illetéktelen módosítástól való elkülönítése érdekében nem engedélyezzük az olyan alkalmazások használatát, mint az Outlook és az Office, mivel gyakran az adathalászat és más típusú támadások célpontjai.

Behatolás elleni védelem és válasz

Az adatokat HTTPS-en és SSL-en keresztül titkosítjuk, hogy ne legyenek elfogva vagy módosítva az Ön és az Azure DevOps közötti átvitel során.

Emellett az Ön nevében az Azure DevOpsban tárolt adatok titkosítása az alábbiak szerint történik:

  • Az Azure SQL-adatbázisokban tárolt adatok titkosítása a transzparens adattitkosítás (TDE) használatával történik. A TDE az adatbázis, a kapcsolódó biztonsági másolatok és az inaktív tranzakciónapló-fájlok valós idejű titkosításával védelmet nyújt a rosszindulatú tevékenységekkel szemben.

  • Az Azure Blob Storage-kapcsolatok titkosítva vannak az átvitel alatt lévő adatok védelme érdekében. Az Azure Blob Storage-ban tárolt inaktív adatok védelme érdekében az Azure DevOps az Azure Storage Service Encryptiont (SSE) használja.

Az Azure-infrastruktúra segítségével az Azure DevOps csapata naplózhatja és figyelheti a szolgáltatás főbb jellemzőit. Ez segít biztosítani, hogy a szolgáltatáson belüli tevékenységek jogszerűek legyenek, és észlelje a szabálysértéseket vagy a megkísérelt biztonsági incidenseket. Emellett minden üzembehelyezési és rendszergazdai tevékenységet biztonságosan naplóz a rendszer, csakúgy, mint az üzemeltetők hozzáférése az éles tárolóhoz. A valós idejű riasztások azért jönnek létre, mert a rendszer automatikusan elemzi a naplóadatokat a potenciálisan rosszindulatú vagy jogosulatlan viselkedés felderítéséhez.

Ha egy lehetséges behatolási vagy magas prioritású biztonsági rést azonosít, a csapat világos választervvel rendelkezik. Ez a terv ismerteti a felelős feleket, az ügyféladatok védelméhez szükséges lépéseket, valamint azt, hogyan lehet kapcsolatba lépni a Microsoft biztonsági szakértőivel. A csapat arról is értesíti a szervezet tulajdonosait, hogy az adatok nyilvánosságra lettek-e hozva vagy sérültek-e, hogy meg tudják tenni a megfelelő lépéseket a helyzet orvoslásához.

Végül a felmerülő fenyegetések elleni küzdelem érdekében az Azure DevOps egy "Biztonsági incidens feltételezése" stratégiát alkalmaz. A Microsoft biztonsági szakértőinek egy speciális csoportja, más néven a vörös csapat, kifinomult támadók szerepét tölti be. Ez a csapat teszteli a biztonsági incidensek észlelését és a reagálást, hogy pontosan mérje a felkészültséget és a valós támadások hatásait. Ez a stratégia megerősíti a fenyegetésészlelést, a reagálást és a szolgáltatás védelmét. Emellett a csapat ellenőrizheti és javíthatja a teljes biztonsági program hatékonyságát.

Adatvédelem

Biztosnak kell lennie abban, hogy az adatait megfelelően kezelik, és jogszerűen használják fel őket. Ennek a garanciának a része a használat megfelelő korlátozása, hogy adatait csak jogszerű okokból használják fel.

Általános adatvédelmi rendelet (GDPR)

Az általános adatvédelmi rendelet (GDPR) a legnagyobb változás az adatvédelmi jogszabályokban Európában az Európai Unió (EU) 95/46/EK adatvédelmi irányelvének 1995-ös bevezetése óta. A GDPR-rendelettel kapcsolatos további információkért tekintse meg a Microsoft Adatvédelmi központ áttekintési oldalát.

Az adatok helye és szuverenitása

Az Azure DevOps a világ következő nyolc földrajzi területén érhető el: Egyesült Államok, Kanada, Európa, Az Egyesült Királyság, India, Ausztrália, Ázsia és a Csendes-óceáni térség, valamint Brazília. A szervezet alapértelmezés szerint a legközelebbi földrajzi helyhez van rendelve, de választhat másik földrajzi helyet is. Ha később meggondolja magát, a Microsoft ügyfélszolgálatának segítségével áttelepítheti a szervezetét egy másik földrajzi helyre.

Az Azure DevOps nem helyezi át vagy replikálja az ügyféladatokat a választott földrajzi helyen kívül. Ehelyett az adatok georeplikálása egy másik régióba történik ugyanazon a földrajzi helyen belül. Az egyetlen kivétel Brazília, amely vészhelyreállítási célból replikálja az adatokat az USA déli középső régiójába.

Megjegyzés

A Microsoft által biztosított macOS-ügynökökön futó buildek és kiadások esetében az adatok át lesznek adva egy GitHub-adatközpontba az USA-ban.

További információ: Azure DevOps-adatok helye.

Bűnüldözési hozzáférés

Bizonyos esetekben előfordulhat, hogy harmadik felek, például a bűnüldözési entitások a Microsofthoz fordulnak, hogy hozzáférjenek az Azure DevOpsban tárolt ügyféladatokhoz. Megpróbáljuk átirányítani a kéréseket a szervezet tulajdonosához megoldás céljából. Amikor a bírósági végzés arra kötelezi, hogy az ügyféladatokat harmadik félnek adja ki, a Microsoft ésszerű erőfeszítéseket tesz annak érdekében, hogy előzetesen értesítse a szervezet tulajdonosát, kivéve, ha erre jogilag tilos.

Egyes ügyfeleknek egy adott földrajzi helyen kell tárolniuk az adattárolást, hogy biztosítsanak egy adott jogi joghatóságot minden bűnüldözési tevékenységhez. Az összes ügyféladat, például a forráskód, a munkaelemek, a teszteredmények, a georedundáns tükrözések és a külső helyek biztonsági másolatai a fent említett földrajzi helyek egyikén maradnak fenn.

Microsoft-hozzáférés

A Microsoft alkalmazottainak időről időre hozzá kell férniük az Azure DevOpsban tárolt ügyféladatokhoz. Elővigyázatosságból minden olyan alkalmazottnak, aki rendelkezik vagy rendelkezik hozzáféréssel az ügyféladatokhoz, át kell adnia egy háttérellenőrzést, amely ellenőrzi a korábbi munkaviszonyt és büntetőítéleteket. Csak akkor engedélyezzük az éles rendszerekhez való hozzáférést, ha élő telephelyi incidens vagy más jóváhagyott karbantartási tevékenység történik, amelyet naplóznak és figyelnek.

Mivel a rendszer nem minden adatát kezeli ugyanúgy, az alábbi adattípusok megkülönböztetése érdekében osztályozzuk az adatokat:

  • Ügyféladatok – az Azure DevOpsba feltöltött adatok.
  • Szervezeti adatok – a szervezet regisztrációja vagy felügyelete során használt adatok.
  • Microsoft-adatok – a szolgáltatás működéséhez szükséges vagy gyűjtött információk.

A besorolás alapján szabályozzuk a használati forgatókönyveket, a földrajzi hely követelményeit, a hozzáférési korlátozásokat és a megőrzési követelményeket.

A Microsoft promóciós használata

A Microsoft időnként kapcsolatba szeretne lépni az ügyfelekkel, hogy tájékoztassa őket az esetlegesen hasznos további funkciókról és szolgáltatásokról. Mivel nem minden ügyfél szeretne kapcsolatba lépni ezekkel az ajánlatokkal, ön is dönthet úgy, hogy letiltja a marketinges e-mail-kommunikációt.

A Microsoft soha nem használja fel az ügyféladatokat adott felhasználók vagy szervezetek konkrét ajánlatainak megcélzására. Ehelyett szervezeti adatokkal és összesített használati statisztikákkal határozzuk meg azokat a csoportokat, amelyeknek adott ajánlatokat kell kapniuk.

Magabiztosság kiépítése

Biztos lehet abban, hogy a Microsoft más erőfeszítéseket tesz az Azure DevOps nevében. Ezek közé tartoznak a Microsoft belső bevezetési szabályzatai, a szolgáltatás állapotában biztosított átláthatóság szintje, valamint az információbiztonsági felügyeleti rendszerek tanúsítványának megszerzésére irányuló előrehaladás.

Belső bevezetés

A Microsoft csapatai belsőleg vezetik be az Azure DevOpsot. Az Azure DevOps csapata 2014-ben költözött egy szervezetbe, és széles körben használja. Tágabb értelemben iránymutatásokat hoztunk létre, amelyek lehetővé teszik a bevezetési terveket más csapatok számára.

Nyilvánvaló, hogy a nagy csapatok fokozatosan mozognak, mint a kisebbek, tekintettel a meglévő DevOps-rendszerekbe való befektetéseikre. A gyors mozgásra képes csapatok számára létrehoztunk egy projektbesorolási megközelítést. A projekt jellemzői alapján értékeli a kockázattűrést annak megállapításához, hogy a projekt megfelelő-e az Azure DevOpshoz. Nagyobb csapatok esetében a bevezetés általában fázisokban történik, nagyobb tervezéssel.

A belső projektekre vonatkozó további követelmények közé tartozik a szervezet Azure AD társítása a felhasználói identitás megfelelő életciklusának és a jelszó összetettségének biztosítása érdekében. Érzékenyebb projektek esetén kétfaktoros hitelesítésre is szükség van.

Megfelelőségi tanúsítványok

Néhányuk szeretné megismerni az adatbiztonsági eljárásaink harmadik féltől származó értékelését. Az Azure DevOps a következő tanúsítványokat érte el:

  • ISO 27001:2013
  • ISO 27018:2019
  • HIPAA (Health Insurance Portability and Accountability Act)
  • BAA (üzlettársi szerződés)
  • Uniós modellként szolgáló szerződéses klauzulák
  • SOC 1 Type 2
  • SOC 2 Type 2
  • Németország C5

Az Azure DevOps SOC-naplózása kiterjed az adatbiztonság, a rendelkezésre állás, a feldolgozási integritás és a bizalmasság vezérlőire. Az Azure DevOps SOC-jelentései a Microsoft Szolgáltatásmegbízhatósági portálon érhetők el.

A lépések elvégzése

A megfelelő adatvédelem megköveteli az aktív részvételt, valamint a rendszergazdák és a felhasználók bevonását. Az Azure DevOpsban tárolt projektadatok csak olyan biztonságosak, mint a végfelhasználói hozzáférési pontok. A projekt bizalmassági szintjével egyezzen az adott szervezetek engedélyeinek szigorúságával és részletességével.

Az adatok besorolása

Az első lépés az adatok besorolása. Sorolja be az adatokat az érzékenység és a kockázati horizont alapján, valamint a sérülést, amely akkor fordulhat elő, ha illetéktelenül sérülnek. Számos vállalat rendelkezik olyan meglévő besorolási módszerekkel, amelyek újra felhasználhatók, amikor a projektek az Azure DevOpsba kerülnek. További információt a Microsoft Trustworthy Computing "Adatok besorolása felhőbeli készültséghez" című dokumentumából tölthet le.

Az Azure Active Directory bevezetése

Az Azure Active Directory (Azure AD) használatával kezelheti a szervezet Azure DevOpshoz való hozzáférését. Azure AD egy másik módot is kínál a felhasználói hitelesítő adatok biztonságának javítására. Azure AD lehetővé teszi, hogy az informatikai részleg kezelje a végfelhasználói hozzáférési szabályzatot, a jelszó összetettségét, a jelszófrissítéseket és a lejáratot, ha a felhasználó elhagyja a szervezetet. Az Active Directory összevonással közvetlenül összekapcsolhatja Azure AD a szervezet központi címtárral, így csak egy helyen kezelheti ezeket a részleteket a vállalat számára.

Az alábbi táblázat összehasonlítja a Microsoft-fiók és Azure AD jellemzőit az Azure DevOps-hozzáféréshez képest:

Tulajdonságok Microsoft-fiók Azure AD
Identitás létrehozója Felhasználó Szervezet
Egyetlen felhasználónév/ jelszó az összes munkaeszközhöz Nem Igen
A jelszó élettartamának & összetettség-vezérlése Felhasználó Szervezet
Az Azure DevOps tagsági korlátai Bármely Microsoft-fiók (MSA) A szervezet címtára
Nyomon követhető identitás Nem Igen
Szervezeti & IP-cím tulajdonjoga Homályos Szervezet
Kétfaktoros hitelesítés regisztrációja Felhasználó Szervezet
Eszközalapú feltételes hozzáférés Nem Szervezet

További információ a támogatás szervezet számára történő konfigurálásáról.

Kötelezővé teheti a kétfaktoros hitelesítés használatát

Előfordulhat, hogy korlátozni szeretné a szervezethez való hozzáférést azáltal, hogy több tényezőt is megkövetel a bejelentkezéshez. A Azure AD több tényezőre is szükség lehet. Az összes hitelesítési kérelemhez például a felhasználónév és a jelszó mellett telefonos hitelesítésre is szükség lehet.

A BitLocker használata

Bizalmas projektek esetén használhatja a BitLockert Windows rendszerű laptopján vagy asztali számítógépén. A BitLocker a Teljes meghajtót titkosítja, amelyen a Windows és az adatok találhatók. Ha a BitLocker engedélyezve van, automatikusan titkosítja az adott meghajtóra mentett fájlokat. Ha laptopja vagy asztali gépe rossz kezekbe kerül, a BitLocker megakadályozza a projektekből származó adatok helyi másolatainak jogosulatlan elérését.

Alternatív hitelesítési hitelesítő adatok használatának korlátozása

A Githez kapcsolódó eszközök alapértelmezett hitelesítési mechanizmusa az alternatív hitelesítés (más néven alapszintű hitelesítés). Ez a mechanizmus lehetővé teszi, hogy a végfelhasználó beállítson egy másodlagos felhasználónevet és jelszót a Git parancssori műveleteihez. Ezzel a felhasználónév- és jelszókombinációval bármely más olyan adathoz is hozzáférhet, amelyhez a felhasználó rendelkezik engedélyekkel. A másodlagos hitelesítési hitelesítő adatok természetüknél fogva kevésbé biztonságosak, mint az alapértelmezett összevont hitelesítés.

Továbbra is választhat a nagyobb biztonság érdekében. Minden kommunikáció HTTPS-en keresztül lesz elküldve, és a jelszó összetettségi követelményei vannak. A szervezetnek továbbra is ki kell értékelnie, hogy szükség van-e további szabályzatra a projekt biztonsági követelményeinek való megfeleléshez. Teljes egészében letilthatja az alternatív hitelesítési hitelesítő adatokat, ha úgy dönt, hogy az nem felel meg a szervezet biztonsági követelményeinek. További információ: Alkalmazáskapcsolat & biztonsági házirendjeinek módosítása a szervezet számára.

Biztonságos hozzáférés a szervezethez

Azure AD lehetővé teszi, hogy a rendszergazdák szabályozni tudják az Azure-erőforrásokhoz és alkalmazásokhoz, például az Azure DevOpshoz való hozzáférést. Ha a feltételes hozzáférés-vezérlés be van állítva, Azure AD ellenőrzi, hogy a felhasználó milyen feltételeket állított be az alkalmazásokhoz való hozzáféréshez. A hozzáférési követelmények teljesülése után a felhasználó hitelesítve lesz, és hozzáférhet az alkalmazáshoz.

Az Azure DevOps támogatja bizonyos típusú feltételes hozzáférési szabályzatok (például IP-kerítés) kikényszerítését az egyéni Azure DevOps-hitelesítési mechanizmusokhoz. Ezek a mechanizmusok közé tartoznak a személyes hozzáférési jogkivonatok, az alternatív hitelesítés, az OAuth és az SSH-kulcsok. Ha a felhasználók egy harmadik féltől származó ügyfélen keresztül férnek hozzá az Azure DevOpshoz, csak az IP-alapú szabályzatok (csak IPv4-alapúak) teljesülnek.

További források