Přehled ochrany dat

Služby Azure DevOps

Azure DevOps Services je aplikace hostovaná v cloudu pro vaše vývojové projekty od plánování až po nasazení. Na základě místních možností s dalšími cloudovými službami spravujeme váš zdrojový kód, pracovní položky, buildy a testy. Azure DevOps využívá infrastrukturu paaS (platforma jako služba) a mnoho služeb Azure, včetně Azure SQL, k zajištění spolehlivé a globálně dostupné služby pro vaše vývojové projekty.

Tento článek popisuje kroky, které Microsoft podnikne, aby vaše projekty byly v bezpečí, dostupné, zabezpečené a soukromé. Popisuje roli, kterou hrajete při zachování bezpečnosti a zabezpečení projektů.

Tento článek je určený pro správce organizace a IT specialisty, kteří spravují své projektové prostředky každý den. Je nejužitečnější pro jednotlivce, kteří už jsou obeznámeni s Azure DevOps a chtějí se dozvědět více o tom, jak Microsoft chrání uložené prostředky v Azure DevOps.

Náš závazek

Microsoft pomáhá zajistit, aby vaše projekty zůstaly bezpečné a zabezpečené bez výjimky. Při ukládání projektů v Azure DevOps využívají různé vrstvy technologií zabezpečení a zásad správného řízení, provozních postupů a zásad dodržování předpisů. Vynucujeme ochranu osobních údajů a integritu neaktivních uložených i přenášených dat.

Hrozby, kterým čelíte, jsou ve čtyřech základních kategoriích: dostupnost dat, dostupnost služeb, zabezpečení služeb a ochrana osobních údajů. Tento článek zkoumá konkrétní hrozby v rámci každé kategorie a vysvětluje, co Azure DevOps dělá, aby je vyřešil. Článek začíná popisem toho, jak se data ukládají a jak Azure DevOps spravuje přístup k vašim datům.

Ochrana dat vyžaduje aktivní zapojení správců auživatelůch zařízení a uživatelů, kteří vědí, jaké kroky je třeba podniknout k ochraně vašich prostředků před neoprávněným zveřejněním a Při udělování oprávnění uživatelským přístupovým bodům buďte explicitní, takže k datům v Azure DevOps přistupují jenom ti správní lidé.

Všechna data byste měli považovat za potenciálně ohrožená bez ohledu na to, kde se jedná nebo jak se používají. Toto prohlášení platí pro data uložená v cloudu i pro data uložená v privátním datacentru. Je důležité klasifikovat data, jejich citlivost a riziko a poškození, které může udělat, pokud dojde k ohrožení zabezpečení. Kategorizujte také data vzhledem k celkové zásadě pro správu zabezpečení informací.

Postaveno v Azure

Azure DevOps hostujeme zcela v datacentrech Azure. Azure DevOps používá mnoho základních služeb Azure, včetně výpočetních prostředků, úložiště, sítí, Azure SQL, správy identit a přístupu a služby Azure Service Bus.

Azure DevOps používá Azure Storage jako primární úložiště pro metadata služeb a zákaznická data. V závislosti na typu dat a požadavcích na úložiště a načítání používá Azure DevOps službu Azure Blob Storage a úložiště Azure SQL Database.

Abychom vám pomohli porozumět přístupu Azure DevOps Services k ochraně dat, tady je několik informací o službách úložiště:

• Azure Blob Storage ukládá velké bloky nestrukturovaných dat. Všechny projekty používají tuto službu. Data zahrnují potenciálně citlivé nebo soukromé informace, například obsah zdrojových souborů a příloh pro pracovní položky. U většiny projektů je většina využitého úložiště tohoto typu nestrukturovaného úložiště objektů blob.

• Azure SQL Database ukládá strukturované a transakční aspekty vaší organizace, včetně metadat projektu, historie správy zdrojového kódu a podrobností pracovních položek. Databázové úložiště umožňuje rychlý přístup k důležitým prvkům projektu. Poskytuje indexy do úložiště objektů blob, aby vyhledaly soubory a přílohy.

Správci můžou spravovat přístup k prostředkům tím , že udělují nebo omezují oprávnění k identitám nebo skupinám uživatelů. Azure DevOps používá federované ověřování identit uživatelů prostřednictvím ID Microsoft Entra a účtů Microsoft.

Během ověřování se uživatel přesměruje na zprostředkovatele ověřování, kde zadají své přihlašovací údaje. Jakmile zprostředkovatel ověřování ověří přihlašovací údaje uživatele, Azure DevOps uživateli vydá ověřovací soubor cookie. Tento soubor cookie umožňuje uživateli zůstat ověřený vůči Azure DevOps.

Tímto způsobem se informace o přihlašovacích údajích uživatele nikdy nesdílí přímo s Azure DevOps. Pro každý prostředek Azure DevOps, ke kterému se uživatel pokouší získat přístup, je ověření oprávnění založeno na explicitních oprávněních uživatele a na oprávněních, která uživatel zdědil prostřednictvím členství ve skupině.

Správci můžou pomocí řízení přístupu chránit přístup k organizaci, kolekci projektů, týmovým projektům a funkcím a datům v oboru týmu. Správci můžou také používat řízení přístupu pro konkrétní prostředky, jako jsou složky pro správu verzí a cesty oblastí pro pracovní položky.

Dostupnost dat

Azure DevOps využívá mnoho funkcí Azure Storage, které pomáhají zajistit dostupnost dat v případě selhání hardwaru, přerušení služeb nebo regionální havárie. Tým Azure DevOps také postupuje podle postupů, které pomáhají chránit data před náhodným nebo škodlivým odstraněním.

Redundance dat

Kvůli ochraně dat při selhání hardwaru nebo služeb geograficky replikuje data zákazníků azure Storage mezi dvěma oblastmi ve stejném geografickém umístění. Azure Storage může například geograficky replikovat data mezi severní a západní Evropou nebo mezi severem a jihem USA.

V případě služby Azure Blob Storage se zákaznická data replikují třikrát v rámci jedné oblasti. Zákaznická data se replikují asynchronně do druhé oblasti ve stejném zeměpisném umístění. Azure proto vždy udržuje ekvivalent šesti kopií vašich dat.

Pokud dojde k závažnému výpadku nebo havárii, můžete mít více kopií, abyste mohli převzít služby při selhání hardwaru do samostatné oblasti a zároveň mít místní redundanci selhání hardwaru v rámci oblasti. V případě úložiště Azure SQL Database se denní zálohování udržuje mimo pracoviště, pokud dojde k regionální havárii.

Pokud jde o redundanci dat a převzetí služeb při selhání:

• Existuje vlastní rozdíl měřený v minutách, kdy Microsoft replikuje vaše data mezi primární a sekundární oblastí.
• Převzetí služeb při selhání do sekundární oblasti je rozhodnutí, které microsoft musí provést centrálně, protože ovlivňuje všechny zákazníky na konkrétní jednotce škálování. S výjimkou extrémních okolností se Společnost Microsoft rozhodne vyhnout se převzetí služeb při selhání, aby se neztratila zákaznická data.
• Azure DevOps nabízí smlouvu o úrovni služeb (SLA) s 99,9% dostupností. Azure DevOps refunduje část měsíčních poplatků, pokud v konkrétním měsíci vynechá danou smlouvu SLA.
• Vzhledem k tomu, že v Brazílii existuje pouze jedna oblast, data zákazníků v Brazílii se replikují do oblasti USA – středojiž pro účely zotavení po havárii.

Chyby se stávají

Microsoft využívá zálohy k určitému bodu v čase pro objekty blob uložené ve službě Azure Blob Storage i v databázích v Rámci služby Azure SQL Database, aby se zajistilo zabezpečení před náhodnou ztrátou dat. Každý účet úložiště udržuje samostatnou kopii všech objektů blob, přičemž změny se připojují k existujícím datům. Tyto zálohy jsou neměnné a eliminují nutnost přepisovat všechna existující úložiště během postupů zálohování.

Azure SQL Database obsahuje standardní funkce zálohování, které využívá Azure DevOps. Vaše data se uchovávají po dobu 28 dnů, přičemž tyto zálohy se také replikují ve spárované oblasti, aby se usnadnilo obnovení během regionálního výpadku.

Odstraněné organizace nebo projekty můžete obnovit během 28denního okna po odstranění. Po uplynutí tohoto časového období se ale tyto entity trvale odstraní a nelze je obnovit. I když tyto zálohy slouží jako zásadní součást pro zotavení po havárii, je nezbytné, aby zákazníci procvičili vhodné strategie správy a zálohování dat, aby zajistili komplexní ochranu dat.

Praktická praxe je kritická

Mít více záloh dat je dobré, ale bez praxe může být obnovení nepředvídatelné. Lidé říkají, že "zálohy nikdy selžou; obnovení provede." I když je příkaz technicky nesprávný, mínění je správné.

Microsoft pravidelně provádí obnovení datových sad ze zálohy. Geograficky redundantní úložiště pravidelně testujeme z Azure. Existuje mnoho kombinací scénářů havárie a poškození dat. Nadále plánujeme a spouštíme nové testy pro tyto scénáře pravidelně.

Dostupnost služby

Azure DevOps nabízí distribuovanou ochranu před dostupností služby (DDoS) a odezvu živého webu, abyste měli jistotu, že máte přístup k vaší organizaci a přidruženým prostředkům.

Ochrana před útoky DDoS

V některých případech může škodlivý útok DDoS ovlivnit dostupnost služby. Azure má systém ochrany před útoky DDoS, který pomáhá předcházet útokům na naši službu. Používá standardní techniky detekce a omezení rizik, jako jsou soubory cookie SYN, omezování rychlosti a limity připojení. Systém je navržený tak, aby odolal útokům nejen zvenčí, ale i z Azure.

Pro útoky specifické pro aplikace, které mohou proniknout do systémů ochrany Azure, Azure DevOps vytváří kvóty a omezování na úrovni aplikací a na úrovni organizace. Tento postup pomáhá zabránit nadměrnému využití klíčových prostředků služby během útoku nebo náhodného zneužití prostředků.

Odpověď živého webu

Ve výjimečných případech můžete vyžadovat odezvu živého webu na problém s dostupností služby. Máme provozní tým, který je neustále dostupný k rychlé identifikaci problému a aby se zapojil do potřebných vývojových týmových prostředků.

Prostředky vývojového týmu pak problém vyřeší. Cílem je také aktualizovat stránku stavu služby během několika minut od zjištění problému, který má vliv na službu. Jakmile prostředky vývojového týmu řeší problém, identifikují původní příčinu a sledují potřebné změny, aby se zabránilo podobným problémům v budoucnu.

Procesy Azure DevOps pro správu živých webů se zaměřují na vaše prostředí a stav služby. Tyto procesy minimalizují dobu detekce, reakce a zmírnění problémů. Všechny technické disciplíny jsou zapojeny a zodpovědné, takže neustálé vylepšování se vyvíjí mimo přímé zkušenosti. Monitorování, diagnostika, odolnost a procesy kontroly kvality se pak v průběhu času vylepšují.

Živá správa webů v Azure DevOps má tři odlišné stopy: telemetrii, správu incidentů a kontrolu živého webu. Tady jsou tyto stopy:

Provozní tým také monitoruje metriky dostupnosti jednotlivých organizací. Tyto metriky poskytují přehled o konkrétních podmínkách, které můžou mít vliv jenom na některé z našich zákazníků. Vyšetřování těchto dat může často vést k cílovým vylepšením, která řeší problémy specifické pro zákazníky. V některých případech vás Microsoft může dokonce kontaktovat přímo, abyste pochopili své zkušenosti a spolupracovali s vámi na vylepšení služby.

Microsoft publikuje smlouvu SLA a poskytuje finanční záruku, abychom zajistili, že tuto smlouvu splníme každý měsíc. Další informace najdete ve sla pro Azure DevOps.

Partnerské týmy nebo závislosti někdy mají incidenty, které ovlivňují Azure DevOps. Všechny partnerské týmy sledují podobné přístupy k identifikaci, řešení a učení se z těchto výpadků služeb.

Zabezpečení služeb

Zabezpečení služeb vyžaduje konstantní bdělost od správných technik návrhu a kódování až po provozní faktory. Microsoft aktivně investuje do prevence bezpečnostních otvorů a detekce porušení zabezpečení. Pokud dojde k porušení zabezpečení, Microsoft používá plány reakce na zabezpečení k minimalizaci úniku dat, ztráty nebo poškození. Další informace naleznete v tématu O zabezpečení, ověřování a autorizaci.

Zabezpečení podle návrhu

Azure DevOps je navržený tak, aby byl zabezpečený. Azure DevOps využívá životní cyklus vývoje zabezpečení Microsoftu v jádru procesu vývoje. Program Microsoft Operational Security Assurance řídí postupy cloudového provozu v Azure DevOps.

Tým Azure DevOps má roční požadavky na školení pro všechny techniky a provozní pracovníky. Tým také sponzoruje neformální schůzky hostované inženýry Microsoftu. Jakmile tým vyřeší problém, který se zobrazí na schůzce, sdílí poznatky získané s ostatními týmy.

Následující metodologie určují požadavky na trénování:

• Modelování hrozeb během návrhu služby
• Dodržování osvědčených postupů pro návrh a kód
• Ověření zabezpečení pomocí standardních nástrojů a testování
• Omezení přístupu k provozním a zákaznickým datům
• Zavedení nových funkcí pevným procesem schvalování

Cloudová služba je stejně zabezpečená jako hostitelská platforma. Azure DevOps využívá PaaS pro většinu své infrastruktury. PaaS automaticky poskytuje pravidelné aktualizace známých ohrožení zabezpečení.

Virtuální počítače hostované v Azure používají infrastrukturu jako službu (IaaS), jako je hostovaná služba sestavení. Tyto image dostávají pravidelné aktualizace, aby zahrnovaly nejnovější opravy zabezpečení dostupné z služba Windows Update. Stejná rigorrie aktualizací platí pro místní počítače, včetně těch počítačů používaných pro nasazení, monitorování a vytváření sestav.

Tým Azure DevOps provádí pravidelné penetrační testování zaměřené na zabezpečení Azure DevOps. Penetrační testování se snaží zneužít živé produkční služby a infrastrukturu Azure DevOps pomocí stejných technik a mechanismů, které útočníci se zlými úmysly používají. Cílem je identifikovat skutečná ohrožení zabezpečení, konfigurace, chyby nebo jiné mezery zabezpečení v řízeném procesu.

Tým zkontroluje výsledky těchto testů, aby identifikoval další oblasti zlepšování a zvýšil kvalitu preventivních systémů a školení. Výsledky nedávných penetračních testů Azure DevOps můžete zkontrolovat na portálu Microsoft Service Trust Portal.

Zabezpečení přihlašovacích údajů

Společnost Microsoft se zavazuje zajistit, aby vaše projekty zůstaly bezpečné a zabezpečené bez výjimky. V Azure DevOps využívají vaše projekty různé vrstvy technologií zabezpečení a zásad správného řízení, provozních postupů a zásad dodržování předpisů. Vynucujeme ochranu osobních údajů a integritu neaktivních uložených i přenášených dat. Kromě toho dodržujeme následující postupy týkající se přihlašovacích údajů nebo tajných kódů, které Azure DevOps ukládá. Další informace o tom, jak zvolit správný mechanismus ověřování, najdete v tématu Pokyny k ověřování.

Osobní přístupové tokeny (PAT)

• Ukládáme hodnotu hash PAT.
• Nezpracované paty generují v paměti na straně serveru. 32 bajtů náhodně vygeneruje prostřednictvím RNGCryptoServiceProvider a sdílí se s volajícím jako řetězec kódovaný jako base-32. Tato hodnota není uložena.
• Hodnota hash PAT generuje v paměti na straně serveru jako HMACSHA256Hash nezpracovaného PAT pomocí symetrického podpisového klíče 64 bajtů uloženého v našem trezoru klíčů.
• Hodnota hash se uloží do naší databáze.

Klíče SSH (Secure Shell)

• Uložíme hodnotu hash ohraničujícího ID organizace a veřejného klíče SSH.
• Nezpracované veřejné klíče poskytují volající přímo přes SSL.
• Hodnota hash SSH generuje v paměti na straně serveru jako HMACSHA256Hash ID organizace a nezpracovaný veřejný klíč pomocí symetrického podpisového klíče 64 bajtů uloženého v našem trezoru klíčů.
• Hodnota hash se uloží do naší databáze.

Přihlašovací údaje OAuth (JWT)

• Problém s přihlašovacími údaji OAuth jako plně self-popisující webové tokeny JSON (JWT) a nejsou uložené v naší službě.
• Deklarace identity v JWT vydaných a prezentovaných službě se ověřují pomocí certifikátu uloženého v našem trezoru klíčů.

Hlášení chyb zabezpečení

Pokud se domníváte, že vaše penetrační testování odhalilo potenciální chybu zabezpečení související se službou Azure DevOps, nahlaste ji Microsoftu do 24 hodin. Další informace naleznete na webové stránce společnosti Microsoft pro hlášení ohrožení zabezpečení počítače.

Bounty program

Azure DevOps se účastní programu Microsoft Bug Bounty. Tento program odměňuje pracovníky v oblasti zabezpečení, kteří nám hlásí problémy, a vyzývá více lidí, aby zajistili zabezpečení Azure DevOps. Další informace najdete v tématu Microsoft Azure DevOps Bounty Program.

Omezení přístupu

Microsoft udržuje přísnou kontrolu nad tím, kdo získá přístup k našemu produkčnímu prostředí a zákaznickým datům. Přístup udělujeme na úrovni minimálních požadovaných oprávnění a až po ověření odůvodnění uživatele. Pokud člen týmu potřebuje přístup k vyřešení naléhavého problému nebo nasadit změnu konfigurace, musí požádat o přístup k produkční službě za běhu. Přístup bude odvolán, jakmile se situace vyřeší.

Žádosti o přístup a schválení sledujeme a monitorujeme v samostatném systému. Veškerý přístup k systému koreluje s těmito schváleními. Pokud zjistíme neschválené přístupy, upozorníme provozní tým, aby ho prošetřil.

Pro veškerý vzdálený přístup k systému používáme dvojúrovňové ověřování. Pokud dojde k odcizení uživatelského jména a hesla některého z našich vývojářů nebo provozních pracovníků, zůstanou data chráněná. Než povolíme vzdálený přístup ke službě, musí dojít k dalším kontrolám ověřování prostřednictvím čipové karty nebo telefonního hovoru na předschválené číslo.

Ke správě a údržbě služby používá Microsoft tajné kódy, jako jsou hesla protokolu RDP, certifikáty SSL a šifrovací klíče. Všechny tyto tajné kódy se spravují, ukládají a přenášejí bezpečně prostřednictvím webu Azure Portal. Jakýkoli přístup k těmto tajným kódům vyžaduje konkrétní oprávnění, která se protokolují a zaznamenávají bezpečně. Všechny tajné kódy se obměňují podle běžného tempa a pokud dojde k události zabezpečení, můžeme je otočit na vyžádání.

Provozní tým Azure DevOps používá k správě služby pracovní stanice posíleného správce. Tyto počítače spouštějí minimální počet aplikací a pracují v logicky segmentovaném prostředí.

Členové provozního týmu musí pro přístup k pracovním stanicím zadat konkrétní přihlašovací údaje s dvojúrovňovým ověřováním. Veškerý přístup se monitoruje a bezpečně protokoluje. Abychom službu izolovali od vnější manipulace, nepovolujeme aplikace, jako je Outlook a Office, protože jsou často cílem spear phishingu a dalších typů útoků.

Ochrana a odezva neoprávněných vniknutí

Data šifrujeme přes PROTOKOL HTTPS a SSL, abychom zajistili, že se během přenosu mezi vámi a Azure DevOps nezachytí ani neupraví. Data, která ukládáme vaším jménem v Azure DevOps, se šifrují následujícím způsobem:

• Data uložená v databázích Azure SQL se šifrují prostřednictvím transparentního šifrování dat. Tato funkce pomáhá chránit před škodlivými aktivitami tím, že v reálném čase provádí šifrování databáze, přidružených záloh a souborů transakčních protokolů v klidovém stavu.

• Připojení azure Blob Storage jsou šifrovaná, aby se vaše přenášená data chránila. Pro neaktivní uložená data uložená ve službě Azure Blob Storage používá Azure DevOps šifrování na straně služby.

Tým Azure DevOps používá infrastrukturu Azure k protokolování a monitorování klíčových aspektů služby. Protokolování a monitorování pomáhá zajistit, aby aktivity v rámci služby byly legitimní, a pomáhají zjišťovat porušení nebo pokusy o porušení zabezpečení.

Všechny aktivity nasazení a správce jsou bezpečně protokolovány, stejně jako přístup operátora k produkčnímu úložišti. Informace protokolu se analyzují automaticky a jakékoli potenciálně škodlivé nebo neoprávněné chování vyvolává výstrahy v reálném čase.

Když tým Azure DevOps identifikuje možné ohrožení zabezpečení nebo ohrožení zabezpečení s vysokou prioritou, má jasný plán reakce. Tento plán popisuje zodpovědné strany, požadované kroky pro zabezpečení zákaznických dat a pokyny k zapojení odborníků na zabezpečení v Microsoftu. Tým také upozorní všechny vlastníky organizace, pokud byla data zpřístupněna nebo poškozena, aby mohli provést příslušné kroky k nápravě situace.

K boji proti vznikajícím hrozbám využívá Azure DevOps strategii předpokládaného porušení zabezpečení . Vysoce specializovaný tým odborníků na zabezpečení v Microsoftu předpokládá roli sofistikovaných nežádoucích pracovníků. Tento tým testuje detekci a reakci na porušení zabezpečení, aby přesně změřil připravenost a dopady reálných útoků. Tato strategie posiluje detekci hrozeb, reakci a obranu služby. Umožňuje také týmu ověřit a zlepšit efektivitu celého programu zabezpečení.

Ochrana proti útokům ransomwaru

Azure DevOps používá ovládací prvky Azure, které pomáhají předcházet útokům ransomwaru, zjišťovat je a reagovat na ně. Další informace o tom, jak Azure pomáhá chránit zákazníky před útoky ransomwarem, najdete v tématu Ochrana ransomwaru v Azure.

Ochrana osobních údajů

Měli byste mít jistotu, že zpracováváme vaše data správně a pro legitimní použití. Součástí této záruky je pečlivé omezení využití.

Obecné nařízení o ochraně dat

Obecné nařízení o ochraně osobních údajů (GDPR) je největší změnou zákonů o ochraně údajů v Evropě od zavedení směrnice Evropské unie (EU) o ochraně údajů 95/46/ES z roku 1995. Další informace o GDPR najdete na stránce s přehledem v Centru zabezpečení Microsoftu.

Rezidence a suverenita dat

Azure DevOps je k dispozici v následujících osmi geografických umístěních po celém světě: USA, Kanada, Evropa, Velká Británie, Indie, Austrálie, Asie a Tichomoří a Brazílie. Ve výchozím nastavení je vaše organizace přiřazená k nejbližšímu umístění. Při vytváření organizace ale můžete zvolit jiné umístění. Pokud později změníte názor, můžete organizaci migrovat do jiného umístění pomocí podpory Microsoftu.

Azure DevOps nepřesouvá ani nereplikuje zákaznická data mimo zvolené umístění. Místo toho se vaše data geograficky replikují do druhé oblasti ve stejném umístění. Jedinou výjimkou je Brazílie, která replikuje data do oblasti USA – středojiž pro účely zotavení po havárii.

Další informace najdete v tématu Umístění dat pro Azure DevOps.

Přístup k vynucení práva

V některých případech můžou třetí strany, jako jsou entity vynucování práva, přistupovat k Microsoftu, aby získaly přístup k zákaznickým datům uloženým v Azure DevOps. Snažíme se žádosti přesměrovat na vlastníka organizace za účelem vyřešení. Když soudní příkaz microsoftu požádá o zveřejnění zákaznických údajů třetí straně, Společnost Microsoft se snaží předem informovat vlastníka organizace, pokud to nebudeme právně zakázáno.

Někteří zákazníci vyžadují úložiště dat v určitém zeměpisném umístění, aby zajistili konkrétní právní jurisdikci pro všechny aktivity vynucování právních předpisů. Všechna zákaznická data, jako je zdrojový kód, pracovní položky, výsledky testů a geograficky redundantní zrcadla a zálohy mimo pracoviště, se uchovávají v jednom z dříve uvedených umístění.

Microsoft Access

Zaměstnanci Microsoftu občas potřebují získat přístup k zákaznickým datům uloženým v Azure DevOps. V rámci preventivních opatření musí všichni zaměstnanci, kteří mají (nebo někdy mít) přístup k zákaznickým datům, předat kontrolu na pozadí, která zahrnuje předchozí zaměstnání a trestní obvinění. Přístup k produkčním systémům povolujeme pouze v případě, že dojde k incidentu živé lokality nebo jiné schválené aktivitě údržby, která se protokoluje a monitoruje.

Vzhledem k tomu, že ne všechna data v našem systému se zpracovávají stejným způsobem, klasifikujeme data do těchto typů:

• Zákaznická data: Co nahrajete do Azure DevOps.
• Data organizace: Informace, které odešlete při registraci nebo správě organizace.
• Data Společnosti Microsoft: Informace potřebné pro nebo shromážděné prostřednictvím provozu služby.

Na základě klasifikace řídíme scénáře použití, požadavky na geografické umístění, omezení přístupu a požadavky na uchovávání informací.

Propagační použití Microsoftu

Microsoft občas chce kontaktovat zákazníky, aby jim dal vědět o dalších funkcích a službách, které by mohly být užitečné. Vzhledem k tomu, že o těchto nabídkách nechcete kontaktovat všechny zákazníky, můžete se odhlásit a vyjádřit výslovný nesouhlas s marketingovou e-mailovou komunikací.

Microsoft nikdy nepoužívá zákaznická data k zacílení konkrétních nabídek pro konkrétní uživatele nebo organizace. Místo toho používáme data organizace a agregujeme statistiky využití na úrovni organizace k určení skupin, které by měly přijímat konkrétní nabídky.

Budování spolehlivosti

Můžete si být jisti jiným úsilím, které Microsoft dělá jménem Azure DevOps. Mezi tyto snahy patří interní zásady přijetí v Microsoftu, úroveň transparentnosti do stavu naší služby a pokrok směrem k získání certifikace našich systémů pro správu zabezpečení informací.

Interní přijetí

Týmy Microsoftu interně přijímají Azure DevOps. Tým Azure DevOps se přesunul do organizace v roce 2014 a používá ho široce. Vytvořili jsme pokyny, které umožňují plány přechodu pro ostatní týmy.

Velké týmy se kvůli investicím do stávajících systémů DevOps pohybují postupně než menší. Pro týmy, které se rychle pohybují, jsme vytvořili přístup klasifikace projektů. Posuzuje odolnost proti rizikům na základě charakteristik projektu, aby určila, jestli je projekt vhodný pro Azure DevOps. U větších týmů k přechodu obvykle dochází ve fázích s větším plánováním.

Další požadavky na interní projekty zahrnují přidružení organizace k ID Microsoft Entra, aby se zajistila správná složitost životního cyklu identit uživatele a hesla. Projekty, které jsou citlivější, vyžadují také dvojúrovňové ověřování.

Certifikace dodržování předpisů

Možná vás bude zajímat vyhodnocení našich postupů pro zabezpečení dat třetích stran. Azure DevOps dosáhl následujících certifikací:

• ISO 27001:2013
• ISO 27018:2019
• ISO 26262:2023
• HIPAA (Health Insurance Portability and Accountability Act)
• Smlouva BAA (Business Associate Agreement)
• Modelové klauzule EU
• Systémové a organizační ovládací prvky (SOC) 1 typ 2
• SOC 2 typ 2
• Německo C5
• IRAP Austrálie
• ENS-Španělsko

Audit SOC pro Azure DevOps se zabývá kontrolami zabezpečení dat, dostupnosti, integrity zpracování a důvěrnosti. Sestavy SOC pro Azure DevOps jsou k dispozici prostřednictvím portálu Microsoft Service Trust Portal.

Dotazník CAIQ (Consensus Assessment Initiative Initiative) pomáhá organizacím vyhodnotit a vyhodnotit postupy a možnosti zabezpečení poskytovatelů cloudových služeb. V souladu s naším závazkem k zabezpečení a transparentnosti jsme nedávno dokončili hodnocení CAIQ pro Azure DevOps. Zveme vás, abyste si zkontrolovali úplnou sestavu na portálu Microsoft Service Trust Portal.

Kroky, které můžete provést

Správná ochrana dat vyžaduje aktivní zapojení od vás, správců a uživatelů. Data projektu uložená v Azure DevOps jsou stejně zabezpečená jako přístupové body uživatele. Shodujte úroveň striktnosti oprávnění a členitosti těchto organizací s úrovní citlivosti vašeho projektu.

Klasifikace dat

Prvním krokem je klasifikace dat. Klasifikujte data na základě citlivosti a horizontu rizik spolu s poškozením, ke kterým může dojít v případě ohrožení zabezpečení. Mnoho podniků má existující metody klasifikace, které můžou opakovaně používat při přechodu projektů do Azure DevOps. Další informace získáte tak, že si můžete stáhnout klasifikaci dat pro připravenost na cloud z Microsoft Trustworthy Computingu.

Adopt Microsoft Entra ID

Pomocí Microsoft Entra ID můžete spravovat přístup vaší organizace k Azure DevOps. Microsoft Entra ID nabízí další způsob, jak zlepšit zabezpečení přihlašovacích údajů uživatelů.

Microsoft Entra ID umožňuje it oddělení spravovat zásady přístupu uživatelů, složitost hesla, aktualizace hesel a vypršení platnosti, když uživatelé opustí vaši organizaci. Prostřednictvím federace služby Active Directory můžete přímo propojit ID Microsoft Entra s centrálním adresářem vaší organizace, takže tyto podrobnosti můžete spravovat pouze v jednom umístění pro váš podnik.

Následující tabulka porovnává charakteristiky účtu Microsoft a Microsoft Entra vzhledem k přístupu k Azure DevOps:

Přečtěte si další informace o konfiguraci této podpory pro vaši organizaci.

Vyžadování dvojúrovňového ověřování

Možná budete chtít omezit přístup k vaší organizaci tím, že k přihlášení vyžaduje více než jeden faktor. Pomocí ID Microsoft Entra můžete vyžadovat více faktorů. Pro všechny žádosti o ověření můžete například vyžadovat ověření telefonem a také uživatelské jméno a heslo.

Použití Nástroje BitLocker

U citlivých projektů můžete bitLocker použít na přenosném nebo stolním počítači s Windows. BitLocker šifruje celou jednotku, na které se nacházejí Windows a vaše data. Když je nástroj BitLocker povolený, automaticky zašifruje všechny soubory, které na této jednotce uložíte. Pokud váš počítač spadá do nesprávných rukou, BitLocker zabrání neoprávněnému přístupu k místním kopiím dat z vašich projektů.

Omezení použití alternativních přihlašovacích údajů pro ověřování

Výchozí mechanismus ověřování pro nástroje související s Gitem je alternativní ověřování (někdy se označuje jako základní ověřování). Tento mechanismus umožňuje uživateli nastavit alternativní uživatelské jméno a heslo pro použití během operací příkazového řádku Gitu. Uživatel může tuto kombinaci uživatelského jména a hesla použít pro přístup k jiným datům, pro která má daný uživatel oprávnění. Ve své podstatě jsou alternativní přihlašovací údaje pro ověřování méně zabezpečené než výchozí federované ověřování.

Stále můžete zvolit vyšší zabezpečení. Veškerá komunikace se odesílá přes PROTOKOL HTTPS a požadavky na složitost hesla. Vaše organizace by měla i nadále vyhodnocovat, jestli potřebuje více zásad pro splnění požadavků na zabezpečení vašich projektů.

Pokud se rozhodnete, že nevyhovuje požadavkům vaší organizace na zabezpečení, můžete zakázat alternativní přihlašovací údaje ověřování. Další informace najdete v tématu Změna zásad připojení aplikací a zabezpečení pro vaši organizaci.

Zabezpečený přístup k vaší organizaci

Správci můžou pomocí ID Microsoft Entra řídit přístup k prostředkům a aplikacím Azure, jako je Azure DevOps. S podmíněným řízením přístupu microsoft Entra ID kontroluje konkrétní podmínky, které jste nastavili pro uživatele pro přístup k aplikaci. Jakmile uživatel splňuje požadavky na přístup, uživatel se ověří a bude mít přístup k aplikaci.

Azure DevOps podporuje vynucování určitých typů zásad podmíněného přístupu (například ohraničení IP adres) pro vlastní mechanismy ověřování Azure DevOps. Mezi tyto mechanismy patří osobní přístupové tokeny, alternativní ověřování, OAuth a klíče SSH (Secure Shell). Pokud vaši uživatelé přistupují k Azure DevOps prostřednictvím klienta třetí strany, dodržují se jenom zásady založené na protokolu IPv4.

Další materiály

• Domovská stránka Azure DevOps
• Umístění dat pro Azure DevOps
• Prohlášení o zásadách ochrany osobních údajů společnosti Microsoft
• Podpora Azure DevOps
• Funkce a služby zahrnuté v Azure DevOps
• Centrum zabezpečení Azure
• Microsoft Security Development Lifecycle