Sdílet prostřednictvím

Sledování a protokolování událostí pro objednávky exportu Azure Data Boxu a Azure Data Boxu Heavy

  • Článek

Objednávka exportu Data Boxu nebo Data Boxu Heavy prochází následujícími kroky: objednávka, nastavení, kopírování dat, vrácení a vymazání dat. Odpovídající jednotlivým krokům v pořadí můžete provést několik akcí pro řízení přístupu k objednávce, auditování událostí, sledování pořadí a interpretaci různých vygenerovaných protokolů.

Tento článek podrobně popisuje různé mechanismy nebo nástroje, které jsou k dispozici pro sledování a audit exportu objednávek pro Data Box nebo Data Box Heavy. Informace v tomto článku platí pro Data Box i Data Box Heavy. V následujících částech se všechny odkazy na Data Box vztahují také na Data Box Heavy.

Následující tabulka obsahuje souhrn kroků exportu Data Boxu a nástrojů dostupných ke sledování a auditování pořadí v jednotlivých krocích.

Fáze objednávky exportu Data Boxu Nástroj ke sledování a auditování
Vytvoření objednávky Nastavení řízení přístupu k objednávce prostřednictvím Azure RBAC
Povolení podrobného protokolu v pořadí
Objednávka byla zpracována. Sledování objednávky prostřednictvím
  • Azure Portal
  • Web přepravního dopravce
  • E-mailová oznámení
Nastavení zařízení Přístup k přihlašovacím údajům zařízení přihlášený v protokolech aktivit
Kopírování dat ze zařízení Kontrola protokolů kopírování
Před kopírováním dat zkontrolujte podrobné protokoly .
Vymazání dat ze zařízení Zobrazení řetězu protokolů opatrovnictví, včetně protokolů auditu a historie objednávek

Nastavení řízení přístupu v objednávce

Můžete určit, kdo má přístup k vaší objednávce při prvním vytvoření objednávky. Nastavte role Azure v různých oborech, abyste mohli řídit přístup k objednávce Data Boxu. Role Azure určuje typ přístupu – jen pro čtení, jen pro čtení a zápis do podmnožina operací.

Dvě role, které je možné definovat pro službu Azure Data Box, jsou:

  • Data Box Reader – mají přístup jen pro čtení k objednávce definované oborem. Můžou zobrazit jenom podrobnosti objednávky. Nemůžou získat přístup k žádným dalším podrobnostem souvisejícím s účty úložiště ani upravovat podrobnosti objednávky, jako je adresa atd.
  • Přispěvatel Data Boxu – může vytvořit objednávku pro přenos dat do daného účtu úložiště, pokud už mají přístup k zápisu do účtu úložiště. Pokud nemají přístup k účtu úložiště, nemůžou ani vytvořit objednávku Data Boxu pro kopírování dat do účtu. Tato role nedefinuje žádná oprávnění související s účtem úložiště ani neuděluje přístup k účtům úložiště.

Pokud chcete omezit přístup k objednávce, můžete:

  • Přiřaďte roli na úrovni objednávky. Uživatel má pouze tato oprávnění definovaná rolemi pro interakci s konkrétní objednávkou Data Boxu a nic jiného.
  • Přiřaďte roli na úrovni skupiny prostředků, uživatel má přístup ke všem objednávkám Data Boxu v rámci skupiny prostředků.

Další informace o navrhovaném použití Azure RBAC najdete v tématu Osvědčené postupy pro Azure RBAC.

Povolení podrobného protokolu v pořadí

Při umísťování objednávky exportu pro Data Box máte možnost povolit shromažďování podrobného protokolu. Tady je obrazovka objednávky, kde můžete povolit podrobný protokol:

Výběr možnosti exportu

Když vyberete možnost Zahrnout podrobný protokol , při kopírování dat z účtu Azure Storage se vygeneruje podrobný soubor protokolu. Tento protokol obsahuje seznam všech souborů, které byly úspěšně exportovány.

Další informace o objednávce exportu najdete v tématu Vytvoření objednávky exportu pro Data Box.

Sledování objednávky

Objednávku můžete sledovat prostřednictvím webu Azure Portal a prostřednictvím webu přepravního dopravce. Pro sledování objednávky Data Boxu jsou kdykoli zavedeny následující mechanismy:

  • Pokud chcete sledovat objednávku, když je zařízení v datacentru Azure nebo v místním prostředí, přejděte na webu Azure Portal na přehled objednávky > Data Boxu.

    Zobrazení stavu objednávky a sledování ne

  • Pokud chcete sledovat objednávku, když je zařízení na cestě, přejděte na web regionálního dopravce, například na web UPS v USA. Zadejte sledovací číslo přidružené k vaší objednávce.

  • Data Box také odesílá e-mailová oznámení kdykoli se změní stav objednávky na základě e-mailů zadaných při vytvoření objednávky. Seznam všech stavů objednávek Data Boxu najdete v tématu Zobrazení stavu objednávky. Pokud chcete změnit nastavení oznámení přidružené k objednávce, přečtěte si článek Upravit podrobnosti o oznámení.

Dotazování protokolů aktivit během instalace

  • Data Box se dostane do místního prostředí v uzamčeném stavu. Pro vaši objednávku můžete použít přihlašovací údaje zařízení dostupné na webu Azure Portal.

    Při nastavování Data Boxu možná budete muset vědět, kdo k přihlašovacím údajům zařízení přistupoval. Pokud chcete zjistit, kdo přistupoval k oknem Přihlašovací údaje zařízení, můžete se dotazovat na protokoly aktivit. Každá akce, která zahrnuje přístup k oknem Přihlašovací údaje o > zařízení, se zaprotokoluje do protokolů aktivit jako ListCredentials akce.

    Dotazy na protokoly aktivit

  • Každé přihlášení k Data Boxu se protokoluje v reálném čase. Tyto informace jsou však k dispozici pouze v protokolech auditu řetězu opatrovnictví po úspěšném dokončení objednávky.

Zobrazení protokolů během kopírování dat

Před kopírováním dat z Data Boxu si můžete stáhnout a zkontrolovat protokol kopírování a podrobný protokol dat zkopírovaných do Data Boxu. Tyto protokoly se generují při kopírování dat z účtu úložiště v Azure do Data Boxu.

Kopírování protokolu

Než zkopírujete data z Data Boxu, stáhněte si protokol kopírování ze stránky Připojit a zkopírovat .

Tady je ukázkový výstup protokolu kopírování, když nedošlo k žádným chybám a během kopírování dat z Azure do zařízení Data Box byly zkopírovány všechny soubory.

<CopyLog Summary="Summary">
  <Status>Succeeded</Status>
  <TotalFiles_Blobs>5521</TotalFiles_Blobs>
  <FilesErrored>0</FilesErrored>
</CopyLog>

Tady je ukázkový výstup, když protokol kopírování obsahuje chyby a některé soubory se nepodařilo zkopírovat z Azure.

<ErroredEntity CloudFormat="AppendBlob" Path="export-ut-appendblob/wastorage.v140.3.0.2.nupkg">
  <Category>UploadErrorCloudHttp</Category>
  <ErrorCode>400</ErrorCode>
  <ErrorMessage>UnsupportBlobType</ErrorMessage>
  <Type>File</Type>
</ErroredEntity><ErroredEntity CloudFormat="AppendBlob" Path="export-ut-appendblob/xunit.console.Primary_2020-05-07_03-54-42-PM_27444.hcsml">
  <Category>UploadErrorCloudHttp</Category>
  <ErrorCode>400</ErrorCode>
  <ErrorMessage>UnsupportBlobType</ErrorMessage>
  <Type>File</Type>
</ErroredEntity><ErroredEntity CloudFormat="AppendBlob" Path="export-ut-appendblob/xunit.console.Primary_2020-05-07_03-54-42-PM_27444 (1).hcsml">
  <Category>UploadErrorCloudHttp</Category>
  <ErrorCode>400</ErrorCode>
  <ErrorMessage>UnsupportBlobType</ErrorMessage>
  <Type>File</Type>
</ErroredEntity><CopyLog Summary="Summary">
  <Status>Failed</Status>
  <TotalFiles_Blobs>4</TotalFiles_Blobs>
  <FilesErrored>3</FilesErrored>
</CopyLog>

Pro export těchto souborů máte následující možnosti:

  • Soubory, které se nedaly zkopírovat přes síť, můžete přenést.
  • Pokud velikost dat přesahuje použitelnou kapacitu zařízení, dojde k částečnému kopírování a všechny soubory, které se nezkopírují, jsou uvedené v tomto protokolu. Tento protokol můžete použít jako vstupní XML k vytvoření nové objednávky Data Boxu a potom tyto soubory zkopírovat.

Podrobný protokol

Podrobný protokol obsahuje seznam všech souborů úspěšně vyexportovaných z účtu Azure Storage. Tento protokol obsahuje také velikosti souborů a výpočty kontrolního součtu.

Podrobný protokol obsahuje informace v následujícím formátu:

<file size = "file-size-in-bytes" crc64="cyclic-redundancy-check-string">\folder-path-on-data-box\name-of-file-copied.md</file>

Tady je ukázkový výstup podrobného protokolu.

  <File CloudFormat="BlockBlob" Path="validblobdata/test1.2.3.4" Size="1024" crc64="7573843669953104266">
  </File><File CloudFormat="BlockBlob" Path="validblobdata/helloEndWithDot..txt" Size="11" crc64="7320094093915972193">
  </File><File CloudFormat="BlockBlob" Path="validblobdata/test..txt" Size="12" crc64="17906086011702236012">
  </File><File CloudFormat="BlockBlob" Path="validblobdata/test1" Size="1024" crc64="7573843669953104266">
  </File><File CloudFormat="BlockBlob" Path="validblobdata/test1.2.3" Size="1024" crc64="7573843669953104266">
  </File><File CloudFormat="BlockBlob" Path="validblobdata/.......txt" Size="11" crc64="7320094093915972193">
  </File><File CloudFormat="BlockBlob" Path="validblobdata/copylogb08fa3095564421bb550d775fff143ed====..txt" Size="53638" crc64="1147139997367113454">
  </File><File CloudFormat="BlockBlob" Path="validblobdata/testmaxChars-123456790-123456790-123456790-123456790-123456790-123456790-123456790-123456790-123456790-123456790-123456790-123456790-123456790-123456790-123456790-123456790-123456790-123456790-123456790-123456790-12345679" Size="1024" crc64="7573843669953104266">
  </File><File CloudFormat="BlockBlob" Path="export-ut-container/file0" Size="0" crc64="0">
  </File><File CloudFormat="BlockBlob" Path="export-ut-container/file1" Size="0" crc64="0">
  </File><File CloudFormat="BlockBlob" Path="export-ut-container/file4096_000001" Size="4096" crc64="16969371397892565512">
  </File><File CloudFormat="BlockBlob" Path="export-ut-container/file4096_000000" Size="4096" crc64="16969371397892565512">
  </File><File CloudFormat="BlockBlob" Path="export-ut-container/64KB-Seed10.dat" Size="65536" crc64="10746682179555216785">
  </File><File CloudFormat="BlockBlob" Path="export-ut-container/LiveSiteReport_Oct.xlsx" Size="7028" crc64="6103506546789189963">
  </File><File CloudFormat="BlockBlob" Path="export-ut-container/NE_Oct_GeoReport.xlsx" Size="103197" crc64="13305485882546035852">
  </File><File CloudFormat="BlockBlob" Path="export-ut-container/64KB-Seed1.dat" Size="65536" crc64="3140622834011462581">
  </File><File CloudFormat="BlockBlob" Path="export-ut-container/1mbfiles-0-0" Size="1048576" crc64="16086591317856295272">
  </File><File CloudFormat="BlockBlob" Path="export-ut-container/file524288_000001" Size="524288" crc64="8908547729214703832">
  </File><File CloudFormat="BlockBlob" Path="export-ut-container/4mbfiles-0-0" Size="4194304" crc64="1339017920798612765">
  </File><File CloudFormat="BlockBlob" Path="export-ut-container/file524288_000000" Size="524288" crc64="8908547729214703832">
  </File><File CloudFormat="BlockBlob" Path="export-ut-container/8mbfiles-0-1" Size="8388608" crc64="3963298606737216548">
  </File><File CloudFormat="BlockBlob" Path="export-ut-container/1mbfiles-0-1" Size="1048576" crc64="11061759121415905887">
  </File><File CloudFormat="BlockBlob" Path="export-ut-container/XLS-10MB.xls" Size="1199104" crc64="2218419493992437463">
  </File><File CloudFormat="BlockBlob" Path="export-ut-container/8mbfiles-0-0" Size="8388608" crc64="1072783424245035917">
  </File><File CloudFormat="BlockBlob" Path="export-ut-container/4mbfiles-0-1" Size="4194304" crc64="9991307204216370812">
  </File><File CloudFormat="BlockBlob" Path="export-ut-container/VL_Piracy_Negtive10_TPNameAndGCS.xlsx" Size="12398699" crc64="13526033021067702820">
  </File>

Podrobné protokoly se také zkopírují do účtu úložiště Azure. Ve výchozím nastavení se protokoly zapisují do kontejneru s názvem copylog. Protokoly se ukládají s následující konvencí vytváření názvů:

storage-account-name/databoxcopylog/ordername_device-serial-number_CopyLog_guid.xml.

Cesta k protokolu kopírování se také zobrazí v okně Přehled portálu.

Tyto protokoly můžete použít k ověření, že soubory zkopírované z Azure odpovídají datům zkopírovaným na místní server.

Použijte soubor podrobného protokolu:

  • Chcete-li ověřit skutečné názvy a počet souborů, které byly zkopírovány z Data Boxu.
  • Chcete-li ověřit skutečné velikosti souborů.
  • Ověření, že crc64 odpovídá nenulovém řetězci. Výpočet CRC (Cyklické redundance) se provádí během exportu z Azure. CrCs z exportu a po zkopírování dat z Data Boxu do místního serveru je možné porovnat. Neshoda CRC značí, že odpovídající soubory se nepodařilo správně zkopírovat.

Získání řetězu protokolů opatrovnictví po vymazání dat

Po vymazání dat z disků Data Boxu podle pokynů k aktualizaci NIST SP 800-88 Revision 1 jsou k dispozici protokoly opatrovnictví. Mezi tyto protokoly patří řetěz protokolů auditu opatrovnictví a historie objednávek. Soubory kusovníku nebo manifestu se také zkopírují s protokoly auditu.

Protokoly auditu opatrovnictví

Protokoly auditu vazby obsahují informace o zapnutí sdílených složek a přístupu ke sdíleným složkám v Data Boxu nebo Data Boxu Heavy, když je mimo datacentrum Azure. Tyto protokoly se nacházejí v těchto umístěních: storage-account/azuredatabox-chainofcustodylogs

Tady je ukázka protokolu auditu z Data Boxu:

9/10/2018 8:23:01 PM : The operating system started at system time ‎2018‎-‎09‎-‎10T20:23:01.497758400Z.
9/10/2018 8:23:42 PM : An account was successfully logged on.
Subject:
	Security ID:		S-1-5-18
	Account Name:		WIN-DATABOXADMIN
	Account Domain:	Workgroup
	Logon ID:		0x3E7
Logon Information:
	Logon Type:		3
	Restricted Admin Mode:	-
	Virtual Account:		No
	Elevated Token:		No
Impersonation Level:		Impersonation
New Logon:
	Security ID:		S-1-5-7
	Account Name:		ANONYMOUS LOGON
	Account Domain:	NT AUTHORITY
	Logon ID:		0x775D5
	Linked Logon ID:	0x0
	Network Account Name:	-
	Network Account Domain:	-
	Logon GUID:		{00000000-0000-0000-0000-000000000000}
Process Information:
	Process ID:		0x4
	Process Name:
Network Information:
	Workstation Name:	-
	Source Network Address:	-
	Source Port:		-
Detailed Authentication Information:
	Logon Process:		NfsSvr
	Authentication Package:MICROSOFT_AUTHENTICATION_PACKAGE_V1_0
	Transited Services:	-
	Package Name (NTLM only):	-
	Key Length:		0
This event is generated when a logon session is created. It is generated on the computer that was accessed.
The subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe.
The logon type field indicates the kind of logon that occurred. The most common types are 2 (interactive) and 3 (network).
The New Logon fields indicate the account for whom the new logon was created, i.e. the account that was logged on.
The network fields indicate where a remote logon request originated. Workstation name is not always available and may be left blank in some cases.
The impersonation level field indicates the extent to which a process in the logon session can impersonate.
The authentication information fields provide detailed information about this specific logon request.
	- Logon GUID is a unique identifier that can be used to correlate this event with a KDC event.
	- Transited services indicate which intermediate services have participated in this logon request.
	- Package name indicates which sub-protocol was used among the NTLM protocols.
	- Key length indicates the length of the generated session key. This will be 0 if no session key was requested.
9/10/2018 8:25:58 PM : An account was successfully logged on.

Stažení historie objednávky

Historie objednávek je dostupná na webu Azure Portal. Pokud je objednávka dokončená a vyčištění zařízení (vymazání dat z disků) je hotové, přejděte na objednávku zařízení a přejděte na podrobnosti objednávky. Máte k dispozici možnost Stáhnout historii objednávky. Další informace naleznete v tématu Stažení historie objednávek.

Pokud procházíte historii objednávek, uvidíte:

  • Informace o sledování dopravce pro vaše zařízení.
  • Události s aktivitou SecureErase Tyto události odpovídají vymazání dat na disku.
  • Odkazy na protokoly Data Boxu Zobrazí se cesty k protokolům auditu, kopírování protokolů a souborů kusovníku.

Tady je ukázka protokolu historie objednávek z webu Azure Portal:

-------------------------------
Microsoft Data Box Order Report
-------------------------------
Name                                               : gus-poland
StartTime(UTC)                              : 9/19/2018 8:49:23 AM +00:00
DeviceType                                     : DataBox
-------------------
Data Box Activities
-------------------
Time(UTC)                 | Activity                       | Status          | Description

9/19/2018 8:49:26 AM      | OrderCreated                   | Completed       |
10/2/2018 7:32:53 AM      | DevicePrepared                 | Completed       |
10/3/2018 1:36:43 PM      | ShippingToCustomer             | InProgress      | Shipment picked up. Local Time : 10/3/2018 1:36:43 PM at AMSTERDAM-NLD
10/4/2018 8:23:30 PM      | ShippingToCustomer             | InProgress      | Processed at AMSTERDAM-NLD. Local Time : 10/4/2018 8:23:30 PM at AMSTERDAM-NLD
10/4/2018 11:43:34 PM     | ShippingToCustomer             | InProgress      | Departed Facility in AMSTERDAM-NLD. Local Time : 10/4/2018 11:43:34 PM at AMSTERDAM-NLD
10/5/2018 8:13:49 AM      | ShippingToCustomer             | InProgress      | Arrived at Delivery Facility in BRIGHTON-GBR. Local Time : 10/5/2018 8:13:49 AM at LAMBETH-GBR
10/5/2018 9:13:24 AM      | ShippingToCustomer             | InProgress      | With delivery courier. Local Time : 10/5/2018 9:13:24 AM at BRIGHTON-GBR
10/5/2018 12:03:04 PM     | ShippingToCustomer             | Completed       | Delivered - Signed for by. Local Time : 10/5/2018 12:03:04 PM at BRIGHTON-GBR
1/25/2019 3:19:25 PM      | ShippingToDataCenter           | InProgress      | Shipment picked up. Local Time : 1/25/2019 3:19:25 PM at BRIGHTON-GBR
1/25/2019 8:03:55 PM      | ShippingToDataCenter           | InProgress      | Processed at BRIGHTON-GBR. Local Time : 1/25/2019 8:03:55 PM at LAMBETH-GBR
1/25/2019 8:04:58 PM      | ShippingToDataCenter           | InProgress      | Departed Facility in BRIGHTON-GBR. Local Time : 1/25/2019 8:04:58 PM at BRIGHTON-GBR
1/25/2019 9:06:09 PM      | ShippingToDataCenter           | InProgress      | Arrived at Sort Facility LONDON-HEATHROW-GBR. Local Time : 1/25/2019 9:06:09 PM at LONDON-HEATHROW-GBR
1/25/2019 9:48:54 PM      | ShippingToDataCenter           | InProgress      | Processed at LONDON-HEATHROW-GBR. Local Time : 1/25/2019 9:48:54 PM at LONDON-HEATHROW-GBR
1/25/2019 10:30:20 PM     | ShippingToDataCenter           | InProgress      | Departed Facility in LONDON-HEATHROW-GBR. Local Time : 1/25/2019 10:30:20 PM at LONDON-HEATHROW-GBR
1/28/2019 7:11:35 AM      | ShippingToDataCenter           | InProgress      | Arrived at Delivery Facility in AMSTERDAM-NLD. Local Time : 1/28/2019 7:11:35 AM at AMSTERDAM-NLD
1/28/2019 9:07:57 AM      | ShippingToDataCenter           | InProgress      | With delivery courier. Local Time : 1/28/2019 9:07:57 AM at AMSTERDAM-NLD
1/28/2019 1:35:56 PM      | ShippingToDataCenter           | InProgress      | Scheduled for delivery. Local Time : 1/28/2019 1:35:56 PM at AMSTERDAM-NLD
1/28/2019 2:57:48 PM      | ShippingToDataCenter           | Completed       | Delivered - Signed for by. Local Time : 1/28/2019 2:57:48 PM at AMSTERDAM-NLD
1/29/2019 2:18:43 PM      | PhysicalVerification           | Completed       |
1/29/2019 3:49:50 PM      | DeviceBoot                     | Completed       | Appliance booted up successfully.
1/29/2019 3:49:51 PM      | AnomalyDetection               | Completed       | No anomaly detected.
2/12/2019 10:37:03 PM     | DataCopy                       | Resumed         |
2/13/2019 12:05:15 AM     | DataCopy                       | Resumed         |
2/15/2019 7:07:34 PM      | DataCopy                       | Completed       | Copy Completed.
2/15/2019 7:47:32 PM      | SecureErase                    | Started         |
2/15/2019 8:01:10 PM      | SecureErase                    | Completed       | Azure Data Box:<Device-serial-no> has been sanitized according to NIST 800-88 Rev 1.
------------------
Data Box Log Links
------------------
Account Name         : gusacct
Copy Logs Path       : databoxcopylog/gus-poland_<Device-serial-no>_CopyLog_<GUID>.xml
Audit Logs Path      : azuredatabox-chainofcustodylogs\<GUID>\<Device-serial-no>
BOM Files Path       : azuredatabox-chainofcustodylogs\<GUID>\<Device-serial-no>

Další kroky