Poznámka:
Přístup k této stránce vyžaduje autorizaci. Můžete se zkusit přihlásit nebo změnit adresáře.
Přístup k této stránce vyžaduje autorizaci. Můžete zkusit změnit adresáře.
Objednávka exportu Data Boxu 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. Informace v tomto článku platí pro Data Box 120, Data Box 525 a Data Box. V následujících částech se všechny odkazy na Data Box vztahují na všechny skladové položky.
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 Povolit podrobný protokol v pořadí |
| Objednávka byla zpracována. |
Sledování objednávky prostřednictvím
|
| Nastavení zařízení | Přístup k přihlašovacím údajům zařízení zaznamenaný v protokolech aktivit |
| Kopírování dat ze zařízení |
Kontrola protokolů kopírování Před kopírováním dat zkontrolujte výpisy protokolů . |
| Vymazání dat ze zařízení | Zobrazit protokoly řetězce 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 v Azure určuje typ přístupu – čtení a zápis, pouze pro čtení, nebo čtení a zápis do podmnožiny operací.
Dvě role, které je možné definovat pro službu Azure Data Box, jsou:
- Data Box Reader – má přístup jen pro čtení k objednávce/objednávkám definované rozsahem. 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ě, nemohou ani vytvořit objednávku systému Data Box 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.
Povolit podrobný protokol v pořadí
Při zadávání objednávky exportu na Data Box máte možnost povolit shromažďování podrobného protokolu. Tady je obrazovka pořadí, kde můžete povolit podrobný protokol:
Když vyberete možnost Zahrnout podrobný protokol, při kopírování dat z účtu úložiště Azure 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 > objednávky Data Boxu.
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
Vaše Data Box přijde na váš pozemek 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 panelu Přihlašovací údaje zařízení, můžete se dotazovat na protokoly aktivit. Každá akce, která zahrnuje přístup k podrobnostem o zařízení a přihlašovacím údajům - blade, se zaprotokoluje do protokolů aktivit jako
ListCredentials.
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. Protokoly se generují, když se data kopírují z vašich úložišť v Azure do zařízení Data Box.
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 .
Následuje 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 soubor k vytvoření nové objednávky Data Boxu a poté zkopírovat tyto soubory.
Podrobný protokol
Podrobný protokol obsahuje seznam všech souborů, které byly úspěšně vyexportovány 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>
Také se zkopírují podrobné protokoly 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í pojmenování:
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ěřit, že crc64 odpovídá nenulovému řetězci. Výpočet kontroly cyklické redundance (CRC) 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ískejte záznamy řetězce opatrovnictví po vymazání dat.
Po vymazání dat z disků Data Boxu podle pokynů NIST SP 800-88 Revize 1 jsou k dispozici protokoly o řetězci opatrovnictví. Tyto protokoly zahrnují protokoly auditu řetězce opatrovnictví a historii objednávek. Soubory BOM nebo manifestu se také zkopírují spolu s protokoly auditu.
Protokoly auditu řetězce opatrování
Protokoly auditu opatrovnictví obsahují informace o zapnutí sdílených složek a přístupu ke sdíleným složkám v Data Boxu, když je mimo datacentrum Azure. Tyto protokoly se nacházejí v těchto umístěních: storage-account/azuredatabox-chainofcustodylogs
Následuje 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 Cesty k protokolům auditu, protokolům kopírování a souborům kusovníku jsou zobrazeny.
Následuje 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
- Zjistěte, jak řešit problémy s Data Boxem.