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 több felhőszolgáltatással felügyeljük a forráskódot, a munkaelemeket, a buildeket és a teszteket. Az Azure DevOps szolgáltatásként (PaaS) nyújtott platforminfrastruktúra és számos Azure-szolgáltatás, köztük az Azure SQL használatával biztosít megbízható, globálisan elérhető szolgáltatást a fejlesztési projektekhez.
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. Leírja, hogy milyen szerepet játszik a projektek biztonságának és biztonságának megőrzésében.
Ez a cikk olyan szervezetgazdáknak és informatikai szakembereknek szól, akik naponta kezelik a projekteszközöket. Azok számára hasznos, akik már ismerik az Azure DevOpst, és többet szeretnének tudni arról, hogyan védi a Microsoft a tárolt eszközöket az Azure DevOpsban.
Elkötelezettségünk
A Microsoft segít biztosítani, hogy a projektek kivétel nélkül biztonságosak és biztonságosak maradjanak. Amikor a projekteket az Azure DevOpsban tárolja, a biztonsági és szabályozási technológiák, az üzemeltetési eljárások és a megfelelőségi szabályzatok több rétegét is élvezhetik. Az adatvédelmet és az integritást mind inaktív, mind átvitel közben érvényesítjük.
A fenyegetések négy alapvető kategóriába sorolhatók: az adatok rendelkezésre állása, a szolgáltatás 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 a problémák elhárításához. A cikk az adatok tárolásának és az Azure DevOps az adatokhoz való hozzáférés kezelésének leírásával kezdődik.
Az adatvédelemhez a rendszergazdák és a felhasználók aktív bevonása szükséges, akik tudják, 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érhetnek hozzá az Adatokhoz az Azure DevOpsban.
Minden adatot potenciálisan veszélynek kell tekinteni, függetlenül attól, hogy hol van, vagy hogyan használják őket. Ez az állítás a felhőben tárolt adatokra és a privát adatközpontokban tárolt adatokra is igaz. Fontos, hogy osztályozza az adatokat, azok bizalmasságát és kockázatát, valamint azokat a károkat, amelyeket akkor okozhat, ha az illetéktelenek megsérülnek. Emellett az adatok kategorizálása az információbiztonság kezelésére vonatkozó általános szabályzathoz képest.
Az Azure-ra épül
Az Azure DevOps teljes mértékben azure-adatközpontokban üzemel. Az Azure DevOps számos alapvető Azure-szolgáltatást használ, többek között a számítást, a tárolást, a hálózatkezelést, az Azure SQL-t, az identitás- és hozzáférés-kezelést, valamint az Azure Service Bust.
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, a tárolási és lekérési követelményektől függően az Azure DevOps az Azure Blob Storage-t és az Azure SQL Database-tárolót használja.
Az Azure DevOps Services adatvédelmi megközelítésének megértéséhez tekintse meg a tárolási szolgáltatások hátterét:
Az Azure Blob Storage strukturálatlan adatok nagy darabjait tárolja. Ezt a szolgáltatást minden projekt 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 legtöbb használatban lévő tároló ilyen típusú strukturálatlan blobtároló.
Az Azure SQL Database tárolja a szervezet strukturált és tranzakciós aspektusait, beleértve a projekt metaadatait, a verziószámozott forráskövetési előzményeket és a munkaelemek részleteit. Az adatbázis-tárolás gyors hozzáférést biztosít a projekt fontos elemeihez. Indexeket biztosít a blobtárolóba a fájlok és mellékletek kereséséhez.
A rendszergazdák a felhasználói identitásokra vagy csoportokra vonatkozó engedélyek biztosítá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 a Microsoft Entra ID-n és a Microsoft-fiókokon keresztül.
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ésszolgáltató ellenőrizte a felhasználó hitelesítő adatait, az Azure DevOps hitelesítési cookie-t ad ki a felhasználónak. Ez a cookie lehetővé teszi a felhasználó számára, hogy hitelesítve maradjon az Azure DevOpson.
Ily módon 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, az engedélyek érvényesítése a felhasználó kifejezett engedélyén és a csoporttagságon keresztül öröklődő engedélyeken alapul.
A rendszergazdák hozzáférés-vezérléssel védhetik a szervezethez, a projektgyűjteményekhez, a csapatprojektekhez, valamint a csoport hatókörébe tartozó adatokhoz és funkciókhoz való hozzáférést. A rendszergazdák hozzáférési vezérlőket is használhatnak bizonyos objektumokhoz, például a verziókövetés mappáihoz és a munkaelemek területútvonalaihoz.
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ához hardverhiba, szolgáltatáskimaradás vagy regionális katasztrófa esetén. Az Azure DevOps csapata emellett olyan eljárásokat is követ, amelyekkel megvédheti az adatokat a véletlen vagy rosszindulatú törléstől.
Adatredundancia
A hardver- vagy szolgáltatáshibák során fellépő adatok védelme érdekében az Azure Storage földrajzilag replikálja az ügyféladatokat két régió között ugyanazon a földrajzi helyen. Az Azure Storage például georeplikálást végezhet Észak- és Nyugat-Európa, illetve Észak- és Dél-Egyesült Államok között.
Az Azure Blob Storage esetében az ügyféladatok háromszor replikálódnak egyetlen régión belül. Az ügyféladatok aszinkron módon replikálódnak egy második régióba ugyanazon a földrajzi helyen. Ezért az Azure mindig az adatok hat példányának megfelelőt tartja fenn.
Ha több példányt használ, a feladatátvételt egy másik régióba is elvégezheti, ha jelentős leállást vagy katasztrófát tapasztal, miközben helyi redundancia áll fenn a régión belüli hardverhibák esetén. Az Azure SQL Database Storage esetében a napi biztonsági mentések helyszíni szinten maradnak, ha regionális katasztrófa történik.
Az adatredundancia és a feladatátvétel tekintetében:
- Van 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 egy adott 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 elkerüli a feladatátvételt, hogy az ügyféladatok ne vesszenek el.
- Az Azure DevOps 99,9 százalékos üzemidővel rendelkező szolgáltatásiszint-szerződést (SLA) kínál. Az Azure DevOps a havi díjak egy részét visszatéríti, ha egy adott hónapban nem veszi észre az SLA-t.
- Mivel Brazíliában csak egy régió található, 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
A véletlen adatvesztés elleni védelem érdekében a Microsoft időponthoz kötött biztonsági mentéseket alkalmaz az Azure Blob Storage-ban tárolt blobokra és az Azure SQL Database-ben található adatbázisokra is. Minden tárfiók külön másolatot tart fenn az összes blobról, és a módosítások hozzá lesznek fűzve a meglévő adatokhoz. Ezek a biztonsági másolatok nem módosíthatók, így nincs szükség a meglévő tárolók újraírására a biztonsági mentési eljárások során.
Az Azure SQL Database az Azure DevOps által használt szabványos biztonsági mentési funkciókat tartalmazza. Az adatok 28 napig maradnak meg, és ezek a biztonsági másolatok egy párosított régióban is replikálódnak, hogy megkönnyítsék a helyreállítást egy regionális kimaradás során.
A törölt szervezeteket vagy projekteket a törlést követő 28 napos ablakban állíthatja helyre. Ha azonban ez az időszak letelik, ezek az entitások véglegesen törlődnek, és nem állíthatók vissza. Bár ezek a biztonsági másolatok kulcsfontosságú szerepet játszanak a vészhelyreállításban, elengedhetetlen, hogy az ügyfelek megfelelő adatkezelési és biztonsági mentési stratégiákat gyakoroljanak adataik átfogó védelmének biztosítása érdekében.
Fontos
- A véletlen törlés azokra a forgatókönyvekre vonatkozik, amelyek a szolgáltatásunkkal kapcsolatos incidens eredményeként keletkeznek. Nem tartalmazza az ügyfelek véletlen törlését (például adattárakat, munkaelemeket, mellékleteket vagy összetevőket).
- Nem támogatjuk az ügyfelek által véletlenül törölt objektumok visszaállítását. Ezek a biztonsági másolatok csak az üzletmenet folytonosságára szolgálnak, és elősegítik a kimaradásból vagy katasztrófahelyzetekből való helyreállítást.
- Ritkán előfordulhat, hogy a törlési folyamat akár 70 napot is igénybe vehet a háttérbeli újrapróbálkozások és a több forrásból származó adatok törlésének szükségessége miatt.
A gyakorlat kritikus fontosságú
Az adatok több biztonsági mentése jó, de gyakorlat nélkül a visszaállítás kiszámíthatatlan lehet. Az emberek azt mondják, hogy "a biztonsági mentések soha nem hiúsulnak meg; a visszaállítások igen." Bár az állítás technikailag helytelen, a vélemény helyes.
A Microsoft rendszeresen beveti az adathalmazok biztonsági mentésből való visszaállítását. Rendszeresen teszteljük a georedundáns tárolást az Azure-ból. A katasztrófa- és adatsérülési forgatókönyvek számos kombinációja létezik. Továbbra is rendszeresen tervezünk és futtatunk új teszteket ezekhez a forgatókönyvekhez.
Elérhető szolgáltatások
Az Azure DevOps elosztott szolgáltatásmegtagadási (DDoS-) védelmet és élő webhelyválaszt kínál annak érdekében, hogy ön 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-ból is ellenálljon a támadásoknak.
Az Azure védelmi rendszerekbe behatoló alkalmazásspecifikus támadások esetén az Azure DevOps alkalmazásszintű és szervezeti szintű kvótákat és szabályozást hoz létre. Ez a gyakorlat segít megelőzni a kulcsszolgáltatás erőforrásainak túlzott használatát egy támadás vagy az erőforrások véletlen helytelen használata során.
Élő webhely válasza
Ritkán előfordulhat, hogy élő webhelyre kell reagálnia a szolgáltatás rendelkezésre állásával kapcsolatos problémára. Van egy operatív csapatunk, amely folyamatosan rendelkezésre áll a probléma gyors azonosításához és a szükséges fejlesztői csapat erőforrásainak bevonásához.
A fejlesztői csapat erőforrásai 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ő percek alatt. Miután a fejlesztői csapat erőforrásai megoldották a problémát, azonosítják a kiváltó okot, é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 szolgáltatás élményére é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 szolgáló időt. Minden mérnöki szemlélet érintett és felelős, így a folyamatos fejlesztések a közvetlen tapasztalatokon keresztül fejlődnek. 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ő sávja van: telemetriai adatok, incidenskezelés és élő webhely-felülvizsgálat. Ezek a számok a következők:
Az operatív csapat az egyes szervezetek rendelkezésre állási mérőszámait 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 megismerje a felhasználói élményét, és önnel együttműködve javítsa a szolgáltatást.
A Microsoft közzétesz egy SLA-t, és pénzügyi garanciát nyújt annak biztosítására, hogy minden hónapban megfelelünk ennek a megállapodásnak. További információ: SLA for Azure DevOps.
Előfordulhat, hogy a partnercsapatok vagy függőségek olyan incidensekkel rendelkeznek, amelyek hatással vannak az Azure DevOpsra. Minden partnercsapat hasonló megközelítéseket követ a szolgáltatáskimaradások azonosításához, feloldásához és tanulásához.
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 biztonsági rések észlelésébe. Incidens esetén a Microsoft biztonsági válaszcsomagokat használ az adatszivárgás, a veszteség vagy a sérülés minimalizálására. További információ: Tudnivalók a biztonságról, a hitelesítésről és az engedélyezésről.
Biztonság tervezés szerint
Az Azure DevOps biztonságossá lett tervezve. 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 az Azure DevOps felhőműveleti eljárásait vezeti végig.
Az Azure DevOps csapata éves képzési követelményekkel rendelkezik az összes mérnök és üzemeltetési személyzet számára. A csapat emellett szponzorálja a Microsoft mérnökei által tartott informális értekezleteket is. Miután a csapat megoldott egy értekezleten megjelenő problémát, megosztja a tanultakat más csapatokkal.
A következő módszertanok határozzák meg a képzési követelményeket:
- Fenyegetésmodellezés a szolgáltatás tervezése során
- Tervezési és kódkezelési ajánlott eljárások követése
- 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
- Új funkciók bevezetésének engedélyezése merev jóváhagyási folyamaton keresztül
A felhőszolgáltatás csak olyan biztonságos, mint a gazdaplatform. Az Azure DevOps a PaaS-t használja az infrastruktúra nagy részére. A PaaS automatikusan rendszeres frissítéseket biztosít az ismert biztonsági résekhez.
Az Azure-ban üzemeltetett virtuális gépek szolgáltatásként használják az infrastruktúrát (IaaS), például egy üzemeltetett buildelési szolgáltatáshoz. Az ilyen rendszerképek rendszeres frissítéseket kapnak, hogy tartalmazzák a Windows Update-ből elérhető legújabb biztonsági javításokat. Ugyanez a frissítési szigor vonatkozik a helyszíni gépekre, beleértve az üzembe helyezéshez, monitorozáshoz és jelentéskészítéshez használt gépeket is.
Az Azure DevOps csapata rendszeres, biztonságközpontú behatolástesztet végez az Azure DevOpsban. A behatolástesztelés az Azure DevOps élő éles szolgáltatásait és infrastruktúráját próbálja kihasználni ugyanazokkal a technikákkal és mechanizmusokkal, amelyeket a rosszindulatú támadók használnak. A cél a valós biztonsági rések, konfigurációk, hibák vagy egyéb biztonsági rések azonosítása egy ellenőrzött folyamat során.
A csapat áttekinti ezeknek a teszteknek az eredményeit, hogy azonosítsa a fejlesztés egyéb területeit, és növelje a megelőző rendszerek és képzések minőségét. Az Azure DevOps legutóbbi behatolási tesztjeinek eredményeit a Microsoft Szolgáltatásmegbízhatósági portálon tekintheti át.
Hitelesítő adatok biztonsága
A Microsoft elkötelezett amellett, hogy a projektek kivétel nélkül biztonságosak és biztonságosak maradjanak. Az Azure DevOpsban a projektek a biztonsági és szabályozási technológiák, az üzemeltetési eljárások és a megfelelőségi szabályzatok több rétegét is kihasználják. Az adatvédelmet és az integritást mind inaktív, mind átvitel közben érvényesítjük. Emellett az Azure DevOps által tárolt hitelesítő adatokkal vagy titkos kódokkal kapcsolatban az alábbi eljárásokat követjük. A megfelelő hitelesítési mechanizmus kiválasztásáról további információt a hitelesítési útmutatóban talál.
Fontos
Az Azure DevOps nem támogatja az alternatív hitelesítő adatok hitelesítését. Ha továbbra is alternatív hitelesítő adatokat használ, határozottan javasoljuk, hogy váltson biztonságosabb hitelesítési módszerre.
Személyes hozzáférési jogkivonatok (PAT-k)
- A PAT kivonatát tároljuk.
- A nyers PAT-k memóriában jönnek létre a kiszolgáló oldalán. 32 bájt véletlenszerűen jön létre az RNGCryptoServiceProvider használatával, és a hívóval 32-es alapkódolt sztringként lesz megosztva. Ez az érték NINCS tárolva.
- A PAT kivonat a kiszolgálóoldalon a nyers PAT HMACSHA256Hash-jaként hozza létre a memóriát a kulcstartóban tárolt 64 bájtos szimmetrikus aláíró kulcs használatával.
- A kivonat az adatbázisunkban lesz tárolva.
Biztonságos rendszerhéj -kulcsok (SSH)
- A csatoló szervezeti azonosító és az SSH nyilvános kulcs kivonatát tároljuk.
- A nyers nyilvános kulcsokat közvetlenül a hívó adja meg SSL-en keresztül.
- Az SSH-kivonat a kiszolgálóoldalon a szervezet azonosítójának HMACSHA256Hashjaként és a nyers nyilvános kulcs HMACSHA256Hashjaként jön létre a kulcstartóban tárolt 64 bájtos szimmetrikus aláíró kulcs használatával.
- A kivonat az adatbázisunkban lesz tárolva.
OAuth hitelesítő adatok (JWT-k)
- Az OAuth hitelesítő adatai teljes mértékben önleíró JSON-webes jogkivonatokként (JWT-ként) jelentkeznek, és nem tárolódnak a szolgáltatásunkban.
- A szolgáltatásunknak kibocsátott és bemutatott JWT-jogcímek a kulcstartóban tárolt tanúsítvánnyal lesznek érvényesítve.
Biztonsági hibák jelentése
Ha úgy véli, hogy a behatolási tesztek az Azure DevOps szolgáltatással kapcsolatos biztonsági hibát tártak fel, 24 órán belül jelentse azt a Microsoftnak. További információkért tekintse meg a Microsoft weblapját a számítógép biztonsági résének jelentéséhez.
Fontos
Bár nem kell értesítenie a Microsoftot a behatolástesztelési tevékenységekről, meg kell felelnie a Microsoft behatolástesztelési szabályainak.
Bounty program
Az Azure DevOps részt vesz a Microsoft Bug Bounty programban. Ez a program megjutalmazza azokat a biztonsági kutatókat, akik problémákat jelentenek nekünk, és arra ösztönzi a felhasználókat, hogy segítsenek az Azure DevOps biztonságának megőrzésében. További információ: Microsoft 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ést a minimálisan szükséges jogosultság szintjén biztosítjuk, és csak a felhasználó indoklásának ellenőrzése után. Ha egy csapattagnak hozzáférésre van szüksége egy sürgős probléma megoldásához vagy egy konfigurációmódosítás üzembe helyezéséhez, akkor az éles szolgáltatáshoz való igény szerinti hozzáférést kell kérnie. A hozzáférés a helyzet megoldása után azonnal vissza lesz vonva.
A hozzáférési kérelmeket és jóváhagyásokat külön rendszerben követjük nyomon és figyeljük. A rendszer minden hozzáférése korrelál ezekhez a jóváhagyásokhoz. Ha nem jóváhagyott hozzáférést észlelünk, riasztást küldünk az operatív csapatnak, hogy vizsgálja meg.
Kéttényezős hitelesítést használunk minden távoli rendszerhozzáféréshez. Ha az egyik fejlesztő vagy üzemeltetési alkalmazott felhasználónevét és jelszavát ellopják, az adatok védettek maradnak. A szolgáltatáshoz való távoli hozzáférés engedélyezése előtt több hitelesítésnek kell történnie intelligens kártyán vagy egy előre megadott számra irányuló telefonhíváson keresztül.
A szolgáltatás kezeléséhez és karbantartásához a Microsoft olyan titkos kódokat használ, mint az RDP-jelszavak, az SSL-tanúsítványok és a titkosítási kulcsok. Ezek a titkos kódok mind biztonságosan kezelhetők, tárolhatók és továbbíthatók az Azure Portalon keresztül. A titkos kódokhoz való hozzáféréshez külön engedély szükséges, amelyet a rendszer biztonságosan naplóz és rögzít. A titkos kulcsok rendszeres időközönként forognak, és igény szerint elforgathatjuk őket, ha biztonsági esemény történik.
Az Azure DevOps üzemeltetési csapata megerősí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ásokhoz való hozzáféréshez. A rendszer minden hozzáférést figyel és biztonságosan naplóz. A szolgáltatás külső illetéktelen beavatkozástól való elkülönítéséhez nem engedélyezzük az olyan alkalmazásokat, mint az Outlook és az Office, mivel gyakran célzott adathalászat és más típusú támadások célpontjai.
Behatolás elleni védelem és válasz
HTTPS-en és SSL-en keresztül titkosítjuk az adatokat, hogy ne legyenek elfogva vagy módosítva az Ön és az Azure DevOps közötti átvitel során. 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 transzparens adattitkosítással titkosítva lesznek. Ez a funkció segít védelmet nyújtani a rosszindulatú tevékenységek ellen az adatbázis valós idejű titkosításával, a kapcsolódó biztonsági másolatokkal és a inaktív tranzakciónapló-fájlokkal.
Az Azure Blob Storage-kapcsolatok titkosítva vannak az átvitel közbeni adatok védelme érdekében. Az Azure Blob Storage-ban tárolt inaktív adatok esetében az Azure DevOps szolgáltatásoldali titkosítást használ.
Az Azure DevOps csapata az Azure-infrastruktúrát használja a szolgáltatás főbb jellemzőinek naplózására és figyelésére. A naplózás és a figyelés segít biztosítani, hogy a szolgáltatáson belüli tevékenységek jogszerűek legyenek, és segítenek észlelni a szabálysértéseket vagy a megkísérelt incidenseket.
A rendszer minden üzembe helyezési és rendszergazdai tevékenységet biztonságosan naplóz, ahogy az üzemi tárolókhoz való operátori hozzáférést is. A rendszer automatikusan elemzi a naplóadatokat, és minden potenciálisan rosszindulatú vagy jogosulatlan viselkedés valós idejű riasztásokat generál.
Ha az Azure DevOps csapata azonosít egy lehetséges behatolási vagy magas prioritású biztonsági rést, egyértelmű válaszcsomaggal rendelkezik. Ez a terv ismerteti a felelős feleket, az ügyféladatok biztonságossá tételéhez szükséges lépéseket, valamint a Microsoft biztonsági szakértőivel való kapcsolattartásra vonatkozó utasításokat. A csapat értesíti a szervezet tulajdonosait is, ha az adatok nyilvánosságra lettek hozva vagy sérültek, hogy meg tudják tenni a megfelelő lépéseket a helyzet megoldásához.
A felmerülő fenyegetések elleni küzdelem érdekében az Azure DevOps feltételezi , hogy megszegi a stratégiát. A Microsoft biztonsági szakértőiből álló, magasan specializált csapat vállalja a kifinomult támadók szerepét. Ez a csapat teszteli a szabálysértések észlelését és a reagálást, hogy pontosan mérje fel a felkészültséget és a valós támadások hatásait. Ez a stratégia erősíti a fenyegetésészlelést, a reagálást és a szolgáltatás védelmét. Emellett lehetővé teszi a csapat számára, hogy ellenőrizze és javítsa a teljes biztonsági program hatékonyságát.
Ransomware támadás elleni védelem
Az Azure DevOps Azure-vezérlőkkel segít megelőzni, észlelni és reagálni a ransomware-támadásokra. További információ arról, hogy az Azure hogyan segít megvédeni az ügyfeleket a zsarolóvírus-támadásoktól: Ransomware Protection az Azure-ban.
Adatvédelem
Biztosnak kell lennie abban, hogy megfelelően és jogszerűen kezeljük az adatait. Ennek a biztosítéknak a része a használat gondos korlátozása.
Általános adatvédelmi rendelet
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-ról további információt a Microsoft Adatvédelmi központ áttekintési oldalán talál.
Az adattárolás helye és szuverenitása
Az Azure DevOps a következő nyolc földrajzi helyen érhető el a világon: Egyesült Államok, Kanada, Európa, Egyesült Királyság, India, Ausztrália, Ázsia és Brazília. Alapértelmezés szerint a szervezet a legközelebbi helyhez van rendelve. A szervezet létrehozásakor azonban másik helyet is választhat. Ha később meggondolja magát, migrálhatja a szervezetet egy másik helyre a Microsoft támogatásával.
Az Azure DevOps nem helyezi át vagy replikálja az ügyféladatokat a kiválasztott helyen kívül. Ehelyett az adatok georeplikálása egy másik régióba történik ugyanazon a helyen belül. Az egyetlen kivétel Brazília, amely vészhelyreállítás céljából replikálja az adatokat az USA déli középső régiójába.
Feljegyzés
A Microsoft által biztosított macOS-ügynökökön futó buildek és kiadások esetében az adatok egy GitHub-adatközpontba kerülnek át a Egyesült Államok.
További információkért tekintse meg az Azure DevOps adathelyeit.
Bűnüldözési hozzáférés
Bizonyos esetekben előfordulhat, hogy harmadik felek, például a bűnüldöző szervek 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ának megoldás céljából. Ha egy bírósági végzés arra kényszeríti a Microsoftot, hogy tegye közzé az ügyféladatokat egy harmadik fél számára, a Microsoft ésszerű erőfeszítéseket tesz annak érdekében, hogy előzetesen értesítse a szervezet tulajdonosát, kivéve, ha jogilag tiltva van.
Egyes ügyfeleknek egy adott földrajzi helyen kell tárolniuk az adataikat, hogy biztosítsák a bűnüldözési tevékenységekre vonatkozó különleges jogi joghatóságot. Az ügyféladatok, például a forráskód, a munkaelemek, a teszteredmények, a georedundáns tükrözések és a helyszíni biztonsági másolatok az egyik fent említett helyen 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 bármikor) hozzáfér az ügyféladatokhoz, át kell adnia egy olyan háttérellenőrzést, amely magában foglalja a korábbi munkaviszonyt és a 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 adatokat az alábbi típusokba soroljuk:
- Ügyféladatok: Az Azure DevOpsba feltöltött adatok.
- Szervezeti adatok: A szervezet regisztrációja vagy felügyelete során beküldött információk.
- 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 a hasznos 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, és letilthatja 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 adatokat használunk, és a szervezeti szinten összesítjük a használati statisztikákat, hogy meghatározzuk azokat a csoportokat, amelyeknek adott ajánlatokat kell kapniuk.
Magabiztosság növelé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ának átláthatósága, valamint az információbiztonság kezelésére szolgáló rendszerek minősítésének megszerzése felé irányuló előrehaladás.
Belső bevezetés
A Microsoft csapatai belsőleg vezetik be az Azure DevOps-t. Az Azure DevOps csapata 2014-ben költözött egy szervezetbe, és széles körben használja. Irányelveket hoztunk létre a bevezetési tervek más csapatok számára történő engedélyezéséhez.
A nagy csapatok a meglévő DevOps-rendszerekbe való befektetésük miatt fokozatosan lépnek át, mint a kisebbek. A gyorsan lépkedő 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 DevOpsnak. A 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 Microsoft Entra-azonosítóval való társítása a megfelelő felhasználói identitás életciklusának és a jelszó összetettségének biztosítása érdekében. A érzékenyebb projektekhez kéttényezős hitelesítésre is szükség van.
Megfelelőségi tanúsítványok
Előfordulhat, hogy érdekli az adatbiztonságra vonatkozó eljárásaink harmadik féltől származó értékelése. Az Azure DevOps a következő minősítéseket érte el:
- ISO 27001:2013
- ISO 27018:2019
- ISO 26262:2023
- Health Insurance Portability and Accountability Act (HIPAA)
- Üzlettársi szerződés (BAA)
- Uniós modellként szolgáló szerződéses klauzulák
- Rendszer- és szervezetvezérlők (SOC) 1 2. típus
- SOC 2 Type 2
- Németország C5
- Ausztrália – IRAP
- ENS-Spanyolország
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 konszenzusértékelési kezdeményezés kérdőíve (CAIQ) segít a szervezeteknek felmérni és értékelni a felhőszolgáltatók biztonsági gyakorlatait és képességeit. A biztonság és az átláthatóság iránti elkötelezettségünknek megfelelően nemrégiben befejeztük az Azure DevOps CAIQ-értékelését. Kérjük, tekintse át a teljes jelentést a Microsoft Szolgáltatásmegbízhatósági portálon.
A lépések elvégzése
A megfelelő adatvédelemhez aktív közreműködésre van szükség Öntől, a rendszergazdáktól és a felhasználóktól. Az Azure DevOpsban tárolt projektadatok csak olyan biztonságosak, mint a felhasználói hozzáférési pontok. Az engedélyek szigorúságának és részletességének megfeleltetése a projekt bizalmassági szintjével.
Az adatok besorolása
Az első lépés az adatok besorolása. A bizalmassági és kockázati horizont alapján osztályozza az adatokat, valamint az esetlegesen felmerülő károkat. Sok vállalat rendelkezik meglévő besorolási módszerekkel, amelyeket újra felhasználhat, amikor a projektek az Azure DevOpsba költöznek. További információkért töltse le a felhőbeli felkészültség adatbesorolását a Microsoft Trustworthy Computing szolgáltatásból.
A Microsoft Entra-azonosító bevezetése
A Microsoft Entra ID használatával kezelheti a szervezet Azure DevOpshoz való hozzáférését. A Microsoft Entra ID egy másik módot kínál a felhasználói hitelesítő adatok biztonságának javítására.
A Microsoft Entra ID lehetővé teszi, hogy az informatikai részleg kezelje a felhasználói hozzáférési szabályzatát, a jelszó összetettségét, a jelszófrissítéseket és a lejáratot, amikor a felhasználók elhagyják a szervezetet. Az Active Directory összevonással közvetlenül csatlakoztathatja a Microsoft Entra-azonosítót a szervezet központi könyvtárához, így csak egy helyen kezelheti ezeket a részleteket a vállalata számára.
Az alábbi táblázat összehasonlítja a Microsoft-fiók és a Microsoft Entra jellemzőit az Azure DevOps-hozzáféréshez képest:
| Tulajdonság | Microsoft-fiók | Microsoft Entra ID |
|---|---|---|
| Identitás létrehozója | User | Organization |
| Egyetlen felhasználónév és jelszó az összes munkaeszközhöz | Nem | Igen |
| Jelszó élettartamának és összetettségének szabályozása | User | Organization |
| Az Azure DevOps tagsági korlátai | Bármely Microsoft-fiók | A szervezet címtára |
| Nyomon követhető identitás | Nem | Igen |
| Szervezeti és IP-tulajdonjog | Homályos | Organization |
| Kéttényezős hitelesítés regisztrációja | User | Organization |
| Eszközalapú feltételes hozzáférés | Nem | Organization |
További információ a támogatás szervezethez való konfigurálásáról.
Kötelezővé teheti a kétfaktoros hitelesítés használatát
Előfordulhat, hogy a szervezethez való hozzáférést úgy szeretné korlátozni, hogy több tényezőt is be kell jelentkeznie. A Microsoft Entra ID használatával több tényezőre is szükség lehet. Az összes hitelesítési kéréshez 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 az egész 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 a számítógép rossz kezekbe kerül, a BitLocker megakadályozza a helyi adatok jogosulatlan elérését a projektekből.
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 a másodlagos hitelesítés (más néven alapszintű hitelesítés). Ez a mechanizmus lehetővé teszi, hogy a felhasználó alternatív felhasználónevet és jelszót állítson be a Git parancssori műveleteihez. A felhasználó ezzel a felhasználónév-jelszó kombinációval hozzáférhet minden olyan adathoz, 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. A rendszer minden kommunikációt HTTPS-en keresztül küld el, és a jelszó összetettségi követelményei vannak. A szervezetnek továbbra is értékelnie kell, hogy több szabályzatra van-e szükség a projektek biztonsági követelményeinek való megfeleléshez.
Letilthatja a másodlagos 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 szabályzatok módosítása a szervezet számára.
Biztonságos hozzáférés a szervezethez
A rendszergazdák a Microsoft Entra ID használatával szabályozhatjá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 működik, a Microsoft Entra-azonosító ellenőrzi, hogy a felhasználó milyen feltételekkel fér hozzá egy alkalmazáshoz. Miután a felhasználó megfelel a hozzáférési követelményeknek, a rendszer hitelesíti a felhasználót, é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 a Secure Shell (SSH) kulcsok. Ha a felhasználók külső ügyfélen keresztül férnek hozzá az Azure DevOpshoz, csak az IPv4-alapú szabályzatok teljesülnek.