技能解封最終對決-卷軸解封金鑰重鎮(Azure Key Vault)

前言

https://ithelp.ithome.com.tw/articles/10214094

 

成本評估

Azure Key Vault 依下列定價面向計費：

  • 左邊：標準
  • 右邊：高階
祕密作業 NT$0.902/10,000 筆交易 NT$0.902/10,000 筆交易
憑證作業2 續約 -每次續約申請 NT$90.163。
所有其他作業 –NT$0.902/10,000 筆交易		 續約 -每次續約申請 NT$90.163。
所有其他作業 –NT$0.902/10,000 筆交易
受控的 Azure 儲存體帳戶金鑰輪替 (預覽) 預覽期間免費。
正式運作價格 – 每個更新 NT$30.055 個3		 預覽期間免費。
正式運作價格 – 每個更新 NT$30.055 個3
受軟體保護的金鑰
RSA 2048 位元金鑰 NT$0.902/10,000 筆交易 NT$0.902/10,000 筆交易
進階金鑰類型 –

RSA 3072 位元、RSA 4096 位元及橢圓曲線密碼編譯 (ECC) 金鑰

 NT$4.509/10,000 筆交易 NT$4.509/10,000 筆交易
受 HSM 保護的金鑰
RSA 2048 位元金鑰 N/A 每月每個金鑰 NT$30.0551 + NT$0.902/10,000 筆交易
進階金鑰類型1 –

RSA 3072 位元、RSA 4096 位元及橢圓曲線密碼編譯 (ECC) 金鑰

 N/A
前 250 組金鑰 每月每個金鑰 NT$150.271
從 251 – 1500 組金鑰 每月每個金鑰 NT$75.136
從 1501 – 4000 組金鑰 每月每個金鑰 NT$27.049
4001 組以上的金鑰 每月每個金鑰 NT$12.022

+ NT$4.509/10,000 筆交易

1只有使用中的 HSM 保護金鑰 (在頭 30 天內使用) 會收費，而 HSM 保護金鑰的每個版本分別計為一份金鑰。請參閱下方的常見問題集，以取得詳細資料。2018 年 11 月 1 號將開始計費。

2Key Vault 不會核發憑證或轉售 CA 的憑證。Key Vault 可簡化並自動執行您向公開 CA 購買憑證時的一些作業，例如註冊或續約。

3儲存體帳戶金鑰會在 Key Vault 中儲存為「祕密」，因此對這些金鑰執行的任何作業 (包括續約) 均適用作業費用 (請參閱上方 [祕密作業] 列)。如需如何定義作業的詳細資料，請參閱下方常見問題集。

Azure Key Vault Q&A

我可在 Key Vault 中儲存什麼？

  • HSM 中匯入或產生金鑰，而當要求 Key Vault 做解密或簽署金鑰時，此作業會在 HSM 內執行。
  • 可使用 HSM 中金鑰進行加密。另外加密編譯作業會在軟體中執行 (相對在 HSM 內部執行)。這些計算會以 Azure 計算角色執行。
  • 祕密是應用程式可用純文字儲存及擷取資料<= 10 KB 如：密碼或 .PFX 檔，此外 Key Vault 可用 HSM 支援的金鑰，讓祕密維持加密狀態並供存取控制。

PS：除金鑰與祕密外還可儲存購買自公開 CA 的 SSL/TLS 憑證，如 Key Vault 目前支援公開 CA，即可透過 Key Vault 自動加以註冊更新。

Azure Key Vault 是否有設定成本？

  • 設定為免費

如果受 HSM 保護的金鑰啟用時間不滿一個月，如何計費？

  • HSM 金鑰收費不會依啟用時間長短依比例計費。只有過去 30 天內至少使用過一次的 HSM 金鑰，才會依照金鑰的建立週年日計費。

 

服務架構

3.png

 

簡易實測環境

圖1. 建立金要保存庫服務定價層請參閱服務價格內容(記得要與保護的標的地區一致)

1.png

圖2. 預設會把目前此帳戶做為管理者權限可以依需求調整，金鑰權限

2.png

圖3. 秘密權限(此範例我選擇全選)

3.png

圖4. 憑證權限(此範例我選擇全選)

4.png

圖5. 網路存取也支援內部虛擬網路，但如果是有對外或是部份PaaS不支援內部虛擬網路情況下仍需要對所有網路允許

5.png

圖6. 透過內部虛擬網路示範

6.png

圖7. 設置驗證無誤

7.png

圖8. 建立完成

8.png

圖9. 此圖中多了一組應用程式是因為儲存加密的關係，詳細可以看此篇章

https://ithelp.ithome.com.tw/articles/10214093

9.png

圖10. 一樣可以設置監視計量可以多維度設置目前僅有三組針對金鑰保存庫的參數包含API 結果，API Hit命中數及API的延遲三項

10.png

圖11. 這看起來是針對磁碟加密實作故意移除讓Key遺失後再還原而產生的

11.png

圖12. 剛剛另外把備份儲存體Key嘗試做還原

14.png

圖13. 不過又顯示衝突提示已存在

15.png

圖14.以為是因為已有一組秘鑰故需要先行移除後才能再還原其他組

16.png

17.png

圖15. 秘鑰也移除了

18.png

圖16. 還原剛剛備份下來的儲存金鑰

20.png

圖17. 還是提示衝突

21.png

圖18. 還原回剛剛的秘鑰

22.png

圖19. 還是失敗…..

23.png

圖20. 一樣是衝突，不動還好一動都掛了．．．．我要再研究研究＠＠

24.png

技能解封最終對決-卷軸祕文添加神秘色彩(Azure Static Data Encryption)

前言

https://ithelp.ithome.com.tw/articles/10214093

 

成本評估

Azure Static Data Encryption 依下列定價面向計費：

29.png

服務架構

以下圖中簡述其流程：

  • Key Vault Administrator 將加密金鑰權限委派授予給儲存體的受控識別。
  • Azure Storage Administrator 用儲存體上的客戶管理金鑰來加密。
  • Azure 會用與儲存體帳戶相關受控識別透過 Azure AD 來驗證 Key Vault 存取權。
  • Azure 儲存體會將帳戶加密金鑰裝在 Key Vault 中。
  • 讀寫過程 Azure 儲存會將要求送至 Key Vault 來作加解密作業。

encryption-customer-managed-keys-diagram.png

 

簡易實測環境

圖1. 對指定的儲存體來作個加密，預設是沒有加密狀態的

1.png

圖2. 一樣透過金鑰保存庫

2.png

圖3. 選擇已有的保存庫

3.png

圖4. 其實Key是可以共用在不同服務的，但正式環境其實還是要作功用上的區隔以避免Key遺失全掛以及未來好的管理規範

4.png

圖5. 來個4096的加密層級吧!~

5.png

圖6. 選擇好剛剛建立好的Key發現原來還是只能2048

7.png

圖7. 只好剛剛砍掉在重建一次

8.png

圖8. 又失敗…..

9.png

圖9. 原來的名稱背景作業還在只是介面不見所以一直名稱衝突

10.png

圖10. 不想等了，換個名稱後就可以選到Key了，真是一坡三折

11.png

圖11. 儲存加密開始

12.png

圖12. 加密完成喽!也產生了一串Key URL 以供未來AP串接之用

13.png

圖13. 以下是公開儲存體上的PDF供人線上閱讀

14.png

圖14. 但為了安全性其實還是要有時效性的，建立SAS簽章

15.png

圖15. 就這短短的五分鐘吧!

16.png

圖16. 建立後有下面的SAS URL

17.png

圖17. 存取沒有問題

18.png

圖18. 剛好超過13:50，馬上因為時效性已過故此URL已經失效以提高安全性

19.png

技能解封最終對決-重要機要防竊攻防 (Azure SQL Structure Security)

前言

https://ithelp.ithome.com.tw/articles/10214095

 

成本評估

Azure SQL Structure Security 依下列定價面向計費：

Azure SQL Database v12 版本原生就支援資料列層級安全，讓存在資料庫裡的資料本身提供更有別於從前的保護機制更為精細控制。

SQL 單一/彈性 (DTU / vCore) 資料庫費用計算

SQL Manage Instance

 

服務架構

簡單說就是可以讓使用者客戶根據各自不同的的使用者屬性透過被賦予不同群組本身的權限資格或執行的內容本身來控制資料庫中各資料列的存取。以公司為例你可以為AI專案部成員僅能夠存取與AI專案相關資料列但非AI的其他專案部門則能存取(不包含 AI 相關資料列)的所有專案資料列。

6.png

 

簡易實測環境

圖1. 已先建立好一台 Azure SQL Database (Only 5 DTU Level) Lab

1.png

圖2. 任何要連到Azure SQL都需要設置白名單信任IP才能連進去執行操作

2.png

圖3. 登入此建立的SQL伺服器連線FQDN與建立服務時一併設置的帳密

3.png

圖4. 已經登入無誤,目前沒有任何資料表

4.png

圖5. 建立三組帳戶分別是Sale1,Sale2及Manager

5.png

圖6. 確實已經建立無誤

5-1.png

圖7. 來建立一張業務資料表包含有以下欄位

6.png

圖8. 我們塞幾筆Sale1與Sale2各自的資料進去

7.png

圖9. 每組帳戶對此資料表給予讀取權限

8.png

圖10. 建立結構描述及內嵌資料表值函式。SalesRep 資料行中資料列相同且帳戶執行查詢時 (@SalesRep = USER_NAME())或執行查詢的帳戶是管理員(USER_NAME() = 'Manager') 時，函數會傳回 1。

9.png

圖11. 建立篩選器述詞加入安全性原則。 啟用此原則須設為 ON。

10.png

圖12. 允許 fn_securitypredicate 函式的 SELECT 權限

11.png

圖13. 現在從每組帳戶的 Sales 資料表來作查詢測試是否有做安全篩選,結果很明顯只有管理者可以看到兩邊的業務資料,而各自業務的Owner只能看到自己的

12.png

圖14. 停用此安全原則為 Off

13.png

圖15. 所有人就都可以相互看到對方資料無安全可言

14.png

技能解封中間章程-狡兔三窟快速戰備(Azure ASR)

前言

https://ithelp.ithome.com.tw/articles/10214092

 

成本評估

Azure ASR 依下列定價面向計費：

前 31 天的價格 過了 31 天後的價格
Azure Site Recovery 至客戶擁有的網站 免費 每月每受保護的執行個體 NT$480.868
Azure Site Recovery 至 Azure 免費 每月每受保護的執行個體 NT$751.355

Azure Site Recovery 是以整個月平均每天受保護的執行個體數目為單位加以計費架設如上半個月持續保護了10 台主機，而下半個月沒有保護任何執行個體，則該月每日平均受保護執行個體的數量換算為 5 台。(因為少了半個月的時間)

而啟用保護的成本外覆寫的資料量也是個別按照吃的空間量計算如複寫了100GB就是吃100GB，受控磁碟在複寫期間的會產生屬於非受控磁碟及分頁 Blob類別的儲存體費用，就是呼應上述的吃法。

最後把機器開起來執行服務以及頻寬資料量也屬於額外要估算的…..記得呦！

Azure ASR Q&A

Azure Site Recovery 的免費層次如何運作？

  • 每個受 Azure Site Recovery 保護的執行個體，在受保護的前 31 天皆為免費。自第 32 天起，就會依上述費率，針對為該執行個體提供的保護進行收費。

假設我已經使用 Azure Site Recovery 一個多月了。這樣的話，每個受保護的執行個體前 31 天仍然免費嗎？

  • 不論已經使用了多久的 Azure Site Recovery。每個受保護的執行個體在前 31 天皆無 Azure Site Recovery 費用如：過去 6 個月保護了 10 個執行個體，而現在您將第 11 個執行個體連線到 Azure Site Recovery，則第 11 個執行個體的前 31 天不會產生任何 Azure Site Recovery 費用。而前 10 個執行個體則因為受保護已超過 31 天，所以會繼續產生 Azure Site Recovery 費用。

SQL Server 授權如何搭配使用 Azure Site Recovery？

  • 軟體保證 – 災害復原權益涵蓋適用於 SQL Server 的 Azure Site Recovery 複寫，並適合所有 Azure Site Recovery 案例 (內部部署至 Azure 的災害復原或跨地區 Azure IaaS 的災害復原)。
  • 使用任何其他 SQL Server 高可用性技術 (如容錯移轉叢集) 或複寫技術 (如 SQL AlwaysOn 可用性群組、資料庫鏡像及記錄傳送) 時，受到下列 SQL Server 授權指導方針的規範：主要資料庫的軟體保證授權涵蓋第一個被動資料庫執行個體 (通常用來確保本機高可用性)。任何其他被動資料庫執行個體 (若是災害復原，其可能位於遠端內部部署資料中心或任何雲端當中) 都需要額外的 SQL Server 授權。如果主要的 SQL 執行個體位於專用硬體，則專用硬體上的軟體保證授權 (而非共用硬體) 涵蓋第一個被動執行個體。如果主要的 SQL 執行個體位於共用硬體，則第一個被動執行個體也在共用硬體涵蓋範圍中。如需詳細資訊，請參閱 SQL Server 授權指南。

服務架構

圖中範例很明顯可以知道當美東的服務失效時可以立刻透過美國中部地區把原來複寫過來的做容錯移轉把機器帶起來盡可能讓RTO / RPO 為最佳

failover.png

 

前置作業

虛擬網路以及異地備援服務建議預先建立，以利後續好管理。

螢幕快照 2019-10-11 14.22.42.png

複寫排程規則可以先後都行

螢幕快照 2019-10-11 14.25.57.png

 

簡易實測環境

圖1. 此唯一台東南亞的Linux主機，連線均正常

螢幕快照 2019-10-11 14.28.33.png

圖2. 機器也只有我這台Ubuntu

螢幕快照 2019-10-11 14.31.52.png

圖3. 選擇到異地備援(中文被翻成嚴重損壞修復)，預設是配對的地區東亞，但其實只要選單上的都是可以依照需求選擇複寫的地區的

1.png

圖4. 我選擇日本東部

2.png

圖5. 不良示範GG，原來版本不支援

螢幕快照 2019-10-11 14.33.13.png

圖6. 看一下白皮書目前Ubuntu只支援14與16兩種

螢幕快照 2019-10-11 14.33.27.png

圖7. 重建一台新的16.04版本連線正常

螢幕快照 2019-10-11 14.40.49.png

圖8. 選擇已設置好的資源群組與虛擬網路

螢幕快照 2019-10-11 14.41.43.png

圖9. 可用性我選擇單一，但實際可以透過選擇可用群組或是可用區域來增強高可用，另外磁碟也可以與來源端的不同，快取儲存就是要跟來源端同地區的儲存體作為複寫過程的暫存複寫的檔案之用

螢幕快照 2019-10-11 14.42.42.png

圖10. 選擇日本東部的復原保存服務與原則(如果沒有則都會新增幫你建立只是名稱後面都會帶亂數，未來不好管理)

螢幕快照 2019-10-11 14.43.25.png

圖11. 設置確認是否無誤，沒問題就可以複寫了

螢幕快照 2019-10-11 14.43.37.png

圖12. 啟用複寫程序進行中

螢幕快照 2019-10-11 14.45.09.png

圖13. 從複寫服務的管理介面在進行中的地方已經顯示為一台

螢幕快照 2019-10-11 14.46.07.png

圖14. 經過約五分鐘後已經顯示受保護的主機狀態良好並且已經有拓墣產生

螢幕快照 2019-10-11 14.51.24.png

圖15. 啟用複寫健康狀態OK

螢幕快照 2019-10-11 14.51.37.png

圖16. 開始進行啟用複寫程序(與地端保護相同一樣要安裝Agent)只是步驟Azure背景處理掉了

螢幕快照 2019-10-11 14.51.48.png

圖17. 啟用複寫程序完成

螢幕快照 2019-10-11 15.14.18.png

圖18. 開始要執行複寫同步作業目前進度為0

螢幕快照 2019-10-11 15.15.07.png

圖19. 開始建立第一組快照

螢幕快照 2019-10-11 15.16.31.png

圖20. 保護完成可以開始執行測試容錯移轉(也有提示)

螢幕快照 2019-10-11 15.18.45.png

圖21. 選快照復原點，我選擇最新的一次狀態

螢幕快照 2019-10-11 15.19.36.png

圖22. 方向是從東南亞到日本東部，並選擇開機後取的虛擬網路

螢幕快照 2019-10-11 15.19.50.png

圖23. 開始執行測試容錯移轉作業

螢幕快照 2019-10-11 15.20.11.png

圖24. 已經把日本東部的複寫主機帶起來了，如最下面所示

螢幕快照 2019-10-11 15.23.43.png

圖25. 預設是沒有Public IP的，我因為要測試故手動指派Public IP給它

螢幕快照 2019-10-11 15.23.59.png

圖26. 指定完成

螢幕快照 2019-10-11 15.24.38.png

圖27. 連線到日本東部這台Lnux OK

螢幕快照 2019-10-11 15.30.57.png

圖28. 沒問題就透過清除容錯移轉程序來移除他，千萬不要手動把機器給刪了，後面ASR這服務要把此紀錄移除就會有難度，切記

螢幕快照 2019-10-11 15.32.03.png

圖29. 沒問題就可以清除了

螢幕快照 2019-10-11 15.32.13.png

圖30. 恢復後一樣只會有東南亞的這台受保護主機嘍！

螢幕快照 2019-10-11 16.04.34.png

圖31. 補充如果是容錯移轉就會是把來源關機而在開啟複寫端(建議都要事先把來源關機尤其是有網路有打通的狀態下)

螢幕快照 2019-10-11 16.06.15.png

圖32. 容錯移轉程序進行中

螢幕快照 2019-10-11 16.09.15.png

圖33. 容錯移轉程序完成

螢幕快照 2019-10-11 16.10.06.png

圖34. 實際是複寫的機器還在建立中，來源端尚未關機

螢幕快照 2019-10-11 16.10.56.png

圖35. 已經把來源端關機

螢幕快照 2019-10-11 16.12.12.png

圖36. 異地複寫的主機連線正常嘍！

螢幕快照 2019-10-11 16.17.02.png

圖37. 這不難理解，因為已經由日本東的主機提供服務，中間一定有差異，所以如果還是要由東南亞來提供則就需要重新保護做複寫

螢幕快照 2019-10-11 16.18.39.png

圖38. 就會由此台轉正

螢幕快照 2019-10-11 16.18.55.png

圖39.  認可完成

螢幕快照 2019-10-11 16.21.02.png

技能解封中間章程-庇護所毀損時光回朔(Azure Backup)

前言

https://ithelp.ithome.com.tw/articles/10214091

 

成本評估

Azure Backup 依下列定價面向計費：

每個執行個體的大小 每月的 AZURE 備份價格
執行個體 < 或 = 50 GB NT$150.2710 + 已使用的儲存體
執行個體 > 50 但 < 或 = 500 GB NT$300.5420 + 已使用的儲存體
執行個體 > 500 GB 每增加 500 GB NT$300.5420 + 已使用的儲存體

範例： 在一個執行個體中有 1.2 TB 的資料，則費用會是 NT$901.63 加上使用的儲存體。而收取的費用為 NT$300.55 (增加的兩個 500 GB) 及 NT$300.55 (剩餘的 200 GB 資料)。

Azure 備份會使用區塊 Blob 儲存體來備份您的執行個體。您有選擇本地備援儲存體 (LRS) 或異地備援儲存體 (GRS) 的彈性。LRS 與 GRS 兩者皆為區塊 Blob 儲存體。

LRS GRS
儲存空間 (GB/月) 每 GB NT$0.6733 每 GB NT$1.3465

 

Azure Backup Q&A

什麼是受保護執行個體？

  • 受保護執行個體是指用於設定備份至 Azure 的電腦、實體或虛擬伺服器。為電腦、伺服器或資料庫設定了備份原則且建立了資料的備份複本之後，執行個體即受到保護。
    • Hyper-V 或 Azure IaaS Hypervisor  內的 VM Guest OS，可以是 Windows Server 或 Linux。
    • 具執行 Windows Server 要備份資料工作負載實體/虛擬的應用伺服器如：MSSQL 、Exchange 、SharePoint、Microsoft Dynamics 及 Windows File Server  角色。若備份或保護這些工作負載，您會需要 Azure 備份伺服器或 System Center Data Protection Manager (DPM)。
    • 執行 Windows OS 個人電腦。
    • SQL Server 包括伺服器上的所有資料庫。

哪些項目會佔用備份儲存體？

  • 備份資料的保留週期
  • 儲存於每個復原點的新變換淨值
  • 備份資料所達到的壓縮等級
  • 排定備份工作的頻率
  • 任何相關的備份中繼資料

還原時的網路流量需要付費嗎？

  • 客戶不會因為任何還原作業或資料出資料中心而收到網路頻寬資料量費用。

須支付儲存體交易的費用嗎？

  • 與定價相同，無需支付使用 Azure 備份的儲存體交易費用。包括在已支付的價格內。

已註冊 ExpressRoute　搭配備份需要支付那些費用？

  • ExpressRoute 費用未涵蓋在 Azure 備份內。客戶將繼續單獨支付 Azure 備份，ExpressRoute 部分則根據選取的連接埠速度來計費。

簡易實測環境(保護共享檔案為例)

圖1. 找到備份保存庫服務

1.png

圖2. 記得選擇的地區要與受保護的檔案共享相同

2.png

圖3. 佈建中

3.png

圖4. 建立備份備援服務總覽畫面

4.png

圖5. 記得屬性地方備份設定預設是GRS(兩倍的成本)，如不需要跨域備份則要選回LRS

5.png

圖6. 保護選擇檔案共用

6.png

圖7. 選擇備份檔案共用的標的

7.png

圖8. 選擇共享資料夾

8.png

圖9. 需要建立排程原則指定你所需的時間做觸發

9.png

圖10. 保留時間最長就是保留半年喽!

10.png

圖11. 建立程序無誤

11.png

圖12. 保護完成後從儲存體端也看到我剛剛的檔案共享已經受保護

12.png

圖13. 回到我原本的檔案共享中已有的檔案清單

13.png

圖14. 剛剛只是啟動保護程序但因為排程時間沒到故並沒有真的觸發

14.png

圖15. 保留時間還是可以自訂的

15.png

圖16. 備份完成後就會出現上次備份的時間與狀態也有還原功能

17.png

圖17. 嘗試刪除一檔案(存貨成本制度文件)

18.png

圖18. 移除完成剩三個檔案

19.png

圖19. 開始透過還原檔案找到剛剛的還原點

20.png

圖20. 選擇你要還原的檔案

21.png

圖21. 選擇復原原來的共享位置上並覆寫(這也可以還原到其他檔案共享區域當作移轉檔案之用)

22.png

圖22. 還原程序設定完成

23.png

圖23. 還原進行中

24.png

圖24. 有個小缺點是其實不快…只有一個檔案但也要超過一分鐘以上

25.png

圖25. 還原完成後已經看到剛剛恢復的存貨成本制度文件喽!

26.png

圖26.

27.png

圖27. 移除共享(最外層了其實就是不可逆的..因為快照也說會一併被移除)

28.png

圖28. 我就是看到此功能還原共用!!想說有這麼厲害怎麼做到

29.png

30.png

圖29. 還真的有快照可以選

31.png

圖30. 覆寫現有OK

32.png

圖31. 還原程序完成，一切看似美好

33.png

圖32. 沒錯….就沒有快照是要怎麼還原呢????但因為他是預覽功能，小弟幫你實驗了！別自己當借鏡阿！

34.png

技能解封中間章程-場域空間強制掠奪(Disk Encryption)

前言

https://ithelp.ithome.com.tw/articles/10214090

 

成本評估

Disk Encryption 依下列定價面向計費：

29.png

服務架構

1.png

前置作業

  • Azure VM (Windows為例)
  • Azure KeyVault is ready.

8.png

 

簡易實測環境

圖1. 此VM磁碟目前尚未加密狀態

1.png

圖2. 因為我只有作業系統，如果有資料碟請自行斟酌

2.png

圖3. 選擇金鑰但因為目前還沒有…….

3.png

圖4. 回到Keyvault在金鑰的地方新建Key

4.png

圖5. 產生一組Key自訂名稱以及金鑰加密大小層級

5.png

圖6. 建立完成

6.png

圖7. 也自動產生金鑰版本

7.png

圖8. 回到VM磁碟加密介面就可以選到剛剛建立的保存庫了

8.png

圖9. 包含剛剛的Key以及版本都是用下拉選單方式進行

9.png

圖10. 加密設定資訊產生後儲存

10.png

圖11. 加密完成會需要重新開機才能套用

11.png

圖12. 加密中

12.png

圖13. 磁碟處也顯示正在更新中

13.png

圖14. 完成後可以看到原本加密狀態從無變成已加密

14.png

圖15. 也同時透過Powershell驗證確實加密無誤

15.png

圖16. 從Keyvault監視上也看到的要求存取,成功率與延遲間的數據紀錄顯示表示有再開始作動

16.png

圖17. 遠端連線進去的確磁碟是被Bitlocker整合加密

21.png

圖18. C槽也有加密鎖頭圖示

22.png

圖19. 金鑰可以先備一份出來也提示只能還原原本的保存庫(同訂閱不同保存庫倒是有機會可以試試….)

17.png

圖20. 好奇開啟Key裡面都是一堆加密後的雜湊

18.png

圖21. 來試試把Key移除當作模擬誤刪遺失

19.png

圖22. 移除完成已空

20.png

圖23. 將機器停止再開機(實驗過如果直接重開機是沒有影響的)果然失敗

23-1.png

圖24. 的確是因為找不到Key導致

24.png

圖25. 還原剛剛下載備份出來的Key

25.png

圖26. 在開機一次在正更新磁碟中

26.png

圖27. 沒問題了!已經能夠在正常連線

27.png

圖28. 如果不要加密選擇無在關機重開就可以喽!

28.png

技能解封中間章程-庇護所疫軍之亂(Azure Anti-malware)

前言

https://ithelp.ithome.com.tw/articles/10214088

 

成本評估

Azure Anti-malware 依下列定價面向計費：

Azure 資訊安全中心透過其免費層與標準層保護所有 Azure 和特定內部部署資源。

在您升級至 Azure 資訊安全中心的標準層時，我們將自動註冊並開始保護您的所有資源，除非您明確決定退出。針對資訊安全中心保護的所有資源，我們將依照以下定價模式向您收費。

目前可透過 Azure 入口網站在訂用帳戶層級啟用 Azure 資訊安全中心。

標準層的前 30 天免費。30 天以後的使用量都依以下定價方案自動收費。

資源類型 免費層 標準層次
虛擬機器 免費 ~NT$438.792/伺服器/月
內含資料 – 500 MB/天
應用程式服務 免費 ~NT$438.792/App Service/月
SQL Database 無法使用 ~NT$438.792/伺服器/月
MySQL (預覽) 無法使用 免費
PostgreSQL (預覽) 無法使用 免費
儲存體 – 保護訂用帳戶內的所有儲存體帳戶 無法使用 NT$0.602/10,000 筆交易
儲存體 – 保護訂用帳戶內的選擇性儲存體帳戶 無法使用 NT$1.203/10,000 筆交易
IoT 裝置 – 依裝置 無法使用 NT$0.0301/月
IoT 裝置 – 依訊息 無法使用 NT$6.011/25,000 筆交易

螢幕快照 2019-09-27 17.10.55.png

 

服務架構

  1. 透過 Azure Portal or PowerShell將 Antimalware 延伸安裝檔推送至 Azure 中一個固定預設位置。
  2. Azure VM 的 Agent 會啟動反惡意程式，將其組態設定套用。讓你如果沒有做任何自訂時就以預設組態來啟動其反惡意程式碼服務。
  3. 執行過程中 Antimalware 會透過 Internet 下載最新保護定義載入到 Azure。
  4. Antimalware 會將紀錄事件寫至 OS 事件記錄中。內容涵蓋反惡意程式碼用戶健康狀態、保護狀態、組態設定更新等定義的資訊。
  5. 透過 Powershell 開啟 VM 反惡意程式碼監視，以便在此事件記錄中產生到你的 Azure Storage 一併寫入。

螢幕快照 2019-09-27 17.35.21.png

 

簡易實測環境

圖1. 在 VM中刀鋒視窗中有個延伸模組，可以從這裡做安裝

1.png

圖2. 這裡有目前Azure都有支援微軟自家或是第三方(有授權問題請自行斟酌)

13.png

圖3. 其中有預設是否有排除不做安全掃描的項目可以依照需求設置，另外也排程掃描

14.png

圖4. 此示範透過資訊安全中心提示建議未安裝 Endpoint

2.png

圖5. 對此機器勾選安裝

3.png

圖6. 我們看到預設就是微軟的Antimalware (此沒的選，就是唯一支持)

4.png

圖7. 其中有預設是否有排除不做安全掃描的項目可以依照需求設置，另外也排程掃描

5.png

圖8. 安裝完成的狀態已顯示以解決

6.png

圖9. 你從回到剛剛VM的延伸模組就看到此已經安裝上去

7.png

圖10. 補充一下監視上需要還需要搭配系統診斷，請啟用Guest Diag

10.png

圖11. 透過在資訊安全中心對於資料收集上工作區選擇以及自動佈署Agent已收集未來的長期發展

11.png

圖12. 設置診斷的通知

12.png

 

 

圖13. 對於VM上從效能到事件都做收集來為後續事件來做請命

15.png

圖14. 針對診斷事件紀錄每個細項調整是否需要

16.png

如何透過 Antimalware 延伸模組開啟監視

  • 如需實際監視主機資安狀態則要透過 Antimalware PowerShell 來啟用診斷讓 VM 中 Antimalware Event 聚集。
  • 透過設定 Azure 診斷延伸模組，從事件記錄檔來源 Microsoft Antimalware 擷取事件至 Azure Storage。其中包含錯誤，警告或詳細資訊等反惡意事件類型。
    以下是 PowerShell 針對 VM 的範例：
    PS C:> Add-AzureAccount
    PS C:> Select-AzureSubscription -SubscriptionName “"
    PS C:> $StorageContext = New-AzureStorageContext -StorageAccountName “" -StorageAccountKey (Get-AzureStorageKey -StorageAccountName “").Primary
    PS C:> Set-AzureServiceAntimalwareExtension -ServiceName “" -Monitoring ON -StorageContext $StorageContext

技能解封中間章程-城池風險維安御林軍(Azure Security Center)

前言

https://ithelp.ithome.com.tw/articles/10214085

 

成本評估

Azure Security Center 依下列定價面向計費：

  • 可透過 Azure Portal 在訂用帳戶層級啟用 Azure 資訊安全中心。
  • 標準層的前 30 天免費。30 天以後的使用量都依以下定價方案自動收費。
資源類型 免費層 標準層次
虛擬機器 免費 ~NT$438.792/伺服器/月
內含資料 – 500 MB/天
應用程式服務 免費 ~NT$438.792/App Service/月
SQL Database 無法使用 ~NT$438.792/伺服器/月
MySQL (預覽) 無法使用 免費 1
PostgreSQL (預覽) 無法使用 免費 1
儲存體 – 保護訂用帳戶內的所有儲存體帳戶 3 無法使用 NT$0.602/10,000 筆交易
儲存體 – 保護訂用帳戶內的選擇性儲存體帳戶 3 無法使用 NT$1.203/10,000 筆交易 2
IoT 裝置 – 依裝置 無法使用 NT$0.0301/月 4
IoT 裝置 – 依訊息 無法使用 NT$6.011/25,000 筆交易 4

1 顯示的定價為預覽價格。價格會在 GA 時變更。如需依資源分類的 ASC 功能詳細資料，請參閱資源專屬文件

2 選擇性儲存體帳戶的安全性變更將於 2020 年 1 月 1 日開始

3 Azure 資訊安全中心目前會保護 Azure Blob

4 (僅限預覽期間) 安全性訊息會根據客戶的 IoT 中樞配額來計算。

Azure Security Center Q&A

異常偵測器 API 的交易組成要素是什麼？

  • 交易是 API 呼叫，其中在時間序列包含最大 1,000 個資料點的要求承載大小。
  • 每累積 1,000 個資料點將計算為其他交易。舉例要求承載大小為 2050 個資料點的 API 呼叫會有 3 筆交易。要求承載大小的上限是 8,640 個資料點。時間序列中的每個資料點都是一組時間戳記/數值配對。

 

服務架構

  • 原生就隸屬在 Azure 中的服務並不需要特別安裝 Agent，如像是 Azure PaaS 類型服務 SQL Database，Storage，WebApps等..都是由資訊安全中心做監視保護。
  • 在 Windows 和 Linux 主機中則需要安裝 Microsoft Monitoring Agent，才可以啟動保護在雲端上或非 Azure 雲端中的企業內部實體或虛擬機器。Azure VM 則透過啟用連接就可以自動佈署讓資訊安全中心來做監視保護。

引用如下

cci2018-azure-security-center-stato-dellarte-e-roadmap-17-638.jpg

 

簡易實測環境

圖1. 資訊安全中心總覽

1.png

圖2. 法規層面功能是鎖住的(需要標準版)

2.png

圖3. 選擇升級為標準版，有30天試用

3.png

圖4. 監視過程還是需要有安裝Agent，同意安裝繼續

4.png

圖5. 安裝完成訊息通知

5.png

圖6. 法規合規性涵蓋四類目前均已解鎖此功能

6.png

圖7. 其中包含評定的結果狀況並都有相對應的建議做法

7.png

圖8. 以下為建議作法步驟的展示

8.png

圖9. 此為展示成功的畫面

9.png

圖10. 可以針對這四種合規類型分別下載報告

10.png

圖11. 報告形式如我所下載的範例

11.png

圖12. 裡面都有個別的完成狀態，可以夾帶給上級長官報告之用

12.png

圖13. 以為示範除了建議外有些服務的建議是會直接帶的解決設置介面上(SQL為例)

13.png

圖14. 設置SQL帳戶擁有AAD來做控管

14.png

圖15. 設置完成(後續此項目就會是通過)

16.png

圖16. 展示目前所有服務間的安全狀況一一列出(解決做法都如上述方式都有其引導)

17.png

圖17. 另外在安全原則上也需要從免費設置成標準(威脅防護才會啟動)

18.png

圖18. 檢視套用的訂閱以及Log分析上述的功能都已經為標準層

19.png

圖19. 檢視網路狀態也有相對應的環形圖統計以及提醒的功能缺失建議改善

20.png

圖20. SQL 健康狀態亦同

21.png

圖21. 此安全解決方案就可以綜觀透過以下功能來做更多監視的強化尤其如非Azure的機器也是能享有其保護監視權力

22.png

圖22. 透過原來Log分析的工作區新增一台地端主機試試

23.png

圖23. 安裝Agent到所需的地端主機(版本自行確認)

24.png

圖24. 開始安裝Agent

25.png

圖25. 安裝過程要把此主機資訊傳送至Azure Log 分析中

26.png

圖26. 包含工作區識別與金鑰

27.png

圖27. 上述通過後就可以開始安裝Agent

28.png

圖28. 安裝完成

29.png

圖29. 以下就是安裝Agent後與安全中心註冊後的主機

35.png

圖30. 一樣也有相關資訊狀態的建議(不過還是需要對照功能差異性，畢竟雲端支援的還是最完善)36.png

 

圖31. JIT 也一直是指標功能

30.png

圖32. 決定好你需要連線的Posts及連線時間後(從開啟那刻算)

31.png

圖33. 回到這台受到JIT保護的網路NSG的清單變化就很明顯看到以但時效過了就會用此Policy來阻擋

34.png

圖34. 檔案完整可以包含機器本身的資料夾檔案路徑會是檔案本身受保護避免竄改

33.png

技能解封中間章程-城池間敢死報信者(Azure Alert)

前言

https://ithelp.ithome.com.tw/articles/10214085

 

成本評估

Azure Alert 依下列定價面向計費：

警示規則的費用會根據其監視的訊號類型與數目而定。訊號可為資源計數、記錄或活動記錄。監視多個訊號的警示規則成本，是監視每個訊號和所有已啟用功能的成本總計。

警示訊號 包含免費單位 價格
計量 每月 10 監視的計量時間序列 每月每個監視的計量時間序列 NT$3.006
記錄 無 15 分鐘 (含) 以上的間隔：每月每個監視的記錄 NT$15.028
10 分鐘的間隔：每月每個監視的記錄 NT$30.055
5 分鐘的間隔：每月每個監視的記錄 NT$45.082
活動記錄 無限制 免費
動態閾值 無 NT$3.006 /每月/每個動態閾值
  • 每個訂用帳戶的設定限制為 100 個計量時間序列警示、100 個活動記錄警示，以及 10 個動作群組。若要提高限制，請連絡 Azure 支援服務。
  • 活動記錄免費供應 90 天。如需於 90 天後保留活動記錄資料，可將活動記錄資料路由至儲存體帳戶或事件中樞。將分別對儲存體及事件中樞收取對應的費用。提取活動記錄資料的 API 呼叫不會產生費用。
  • Azure 資訊安全中心 (ASC) 附帶提供的警示目前並不收費。
  • 為健全準則建立的警示並不收費。

動態警示會就動態閾值功能與基礎計量警示收費。

範例如下：

  1. 為 10 部 VM 監視 CPU 使用率與 RAM 使用量 (即 2 計量時間序列)，且啟用動態閾值的警示規則價格，以下列公式計算：
    • 警示規則價格 + 動態閾值價格。
    • (10 部 VM * 每部 VM 2 個計量時間序列 – 10 個免費單位) * 每月每個計量時間序列警示規則 NT$3.006 + [(10 部 VM * 每部 VM 2 個計量時間序列) * 每月每個動態閾值 NT$3.006] = 每月 NT$90.163。
  2. 每 15 分鐘查詢 1 個 Log Analytics 工作區是否有 404 錯誤的警示規則價格，以下列公式計算：
    • 1 個工作區 * 每個記錄警示查詢 1 * 每月每個記錄警示規則 NT$15.028 = 每月 NT$15.028。

通知觸發

功能 包含免費單位 價格
ITSM 連接器建立或更新事件12 每月 1,000個事件 NT$150.271/1,000 事件
電子郵件 每月 1,000 封電子郵件 NT$60.109/100,000 封電子郵件
推播通知 (對 Azure 行動應用程式) 每月 1,000 則通知 NT$60.109/100,000 則通知
安全的 Webhook 1 個安全的 Webhook NT$180.326/1,000,000 個安全的 Webhook
Webhook 每月 100,000 個 Webhook NT$18.033/1,000,000 個 Webhook

Azure Alert Q&A

上述定價是否適用活動記錄、服務健康狀態與資源健康狀態警示規則？

  • 可繼續免費使用活動記錄、服務健康狀態與資源健康狀態警示規則。

警示通知 (透過 Azure 動作群組) 的費用是否包含在警示規則的費用內？

  • 警示通知會根據使用的通知類型個別收費。

如果還是傳統警示平台上的既有客戶，是否適用上述的警示規則定價？

  • 上列定價適用新的警示平台。若你將現有警示規則從傳統警示平台移轉到新平台，則上述定價一律適用。

 

服務架構

警示規則需要備觸發而有進一步您設置所採取的動作。規則可以是啟用或停用狀態。而警示只有在啟用狀態才會觸發。

以下說明警示規則的關鍵屬性
1.目標資源 – 定義可用於警示任何 Azure 範圍資源。標的如：VM、Storage、VMSS(自動擴展)、WebApps、SQL等資源。均可指定多個資源作為警示規則的目標。
2.信號 – 由目標資源做觸發，可以是以下類型如：計量、活動記錄、Application Insights。
3.準則 – 用於目標資源信號邏輯間的組合。

  • CPU >= 70%
  • MEM >= 75%
  • 主機回應時間 >= 1sec

4.嚴重性 – 符合警示規則中指定準則之後的警示嚴重性。 嚴重性的範圍可從 0 到 4。

  • Sev 0 = Critical(重大)
  • Sev 1 = Error(錯誤)
  • Sev 2 = Warning(警告)
  • Sev 3 = Informational(資訊)
  • Sev 4 = Verbose(詳細資訊)

5.動作 – 觸發警示時採取執行的動作群組。

1.png

 

簡易實測環境

圖1. 找到警示服務

1.png

圖2. 先建立新的警示規則

2.png

圖3. 選擇你要警示的資源類型

3.png

圖4. 選擇WebApp 重新開機為觸發條件

4.png

圖5. 可以選擇圖表最近的時段區間，包含警示的邏輯

5.png

圖6. 已確定規則條件完成

6.png

圖7. 條件規則為啟用中

7.png

圖8. 選擇動作群組

8.png

圖9. 接下來常用的寄送郵件通知，不過這是改成對ARM的角色成員發送

9.png

圖10. 選擇Owner

10.png

圖11. 設置郵件通知完成

11.png

圖12. 動作群組此規則已啟用

12.png

圖13. 此為新功能我們進去看看

13.png

圖14. 決定在哪個資源群組下選取的資源服務

14.png

圖15. 選擇觸發後的執行動作

15.png

圖16. 完成後回到規則檢視其中嚴重層級被歸類為4

19.png

圖17. 所以如果此層級不需要觸發可以在此勾選

16.png

圖18. 設置動作規則確認欄位是否正確，如果無誤就確定

20.png

圖19. 透過檢視傳統警示

21.png

圖20. 開啟活動紀錄警示

22.png

圖21. 這裡才有剛剛設置的規則

23.png

 

 

 

 

 

技能解封中間章程-城池間的隱形之眼(Azure Metrics)

前言

https://ithelp.ithome.com.tw/articles/10214083

 

成本評估

Azure Metrics 依下列定價面向計費：

計量代表一組時間序列。會依監視的時間序列數以及進行的 API 呼叫數計費。目前，計量查詢和自訂查詢不會產生任何費用。計量查詢與自訂計量的收費標準將自 2019 年 12 月 1 日起生效。

功能 包含免費單位 價格
標準計量 無限制 免費
自訂計量 每月 150 MB NT$7.754/MB：150-100,000 MB

NT$4.539/MB：100,000-250,000 MB

NT$1.834/MB：高於 250,000 MB
計量查詢 每月 1,000,000 個標準 API 呼叫 NT$0.301/1,000個標準 API 呼叫

標準計量類型如下：

https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported

計量查詢費用以標準 API 呼叫數目為依據。標準 API 呼叫是會分析 1,440 個資料點的呼叫 (1,440 也是每個計量每天可儲存的總資料點數)。

如 API 呼叫分析 1,440 個以上的資料點，即計為多個標準 API 呼叫。如 API 呼叫分析 1,440 個以下的資料點，則計為不到一個 API 呼叫。標準 API 呼叫的數目會每天計算，計算方式為每日分析的資料點總數除以 1,440。

計量免費供應 90 天。若要在 90 天後保留計量資料，可將計量資料路由至儲存體帳戶、Azure Log Analytics 工作區或事件中樞。將分別對儲存體、Log Analytics 及事件中樞收取對應的費用。此外，計量查詢將會為路由資料所需的對應 API 呼叫計費

範例如下：

  • 分析 2,000 個資料點的 API 呼叫會計為 2,000/1,440 = 1.4 個標準 API 呼叫。
  • 分析 200 個資料點的 API 呼叫會計為 200/1,440 = 0.1 個標準 API 呼叫。
  • 以一分鐘資料粒度從 100 部 VM 追蹤五個計量一天的情況下，會產生 720,000 個資料點，進而轉譯成每天 (720,000/1,440) 500 個標準 API 呼叫。

 

Azure Metrics Q&A

支援 Azure 監視計量的參考有哪些？

https://docs.microsoft.com/zh-tw/azure/azure-monitor/platform/metrics-supported

 

服務架構

Azure Monitor 所收集的資料均符合以下兩種類型：

  • 計量則是描述系統在當前時間區間的某個行為表現。此屬輕量服務能支援近乎即時的實例。
  • 記錄則包含各種不同類型資料，並針對每個類型組織成不同的屬性。除效能資料外，還會將事件和追蹤的遙測資料儲存為記錄，並整合一起來進行分析。

Azure Monitor 可從各種來源收集資料。包含各層級中的應用程式監視資料，範圍從您的應用程式、它所倚賴的任何作業系統和服務再到平台本身。所收集的資料來源類型如下：

  • 應用程式監視資訊 – 程式碼效能或相關功能資訊。
  • Guest OS 監視資訊 – 關於應用程式執行所在作業系統的資料。可以是 Azure 以外包含其他雲端或企業內部監視。
  • Azure 資源監視資訊 – Azure 資源操作行為資訊。
  • Azure 訂閱帳戶監視資訊 – 關於訂閱帳戶作業管理及 Azure 本身健康監視情況的資訊。
  • Azure 租用戶(tenant)監視資訊 – 租用戶層級作業相關如：Azure Active Directory。

1.png

簡易實測環境

圖1. 其實每個服務下的刀鋒視窗只要有計量服務都可以直接運用，結果都一樣但前著是針對明確的目標標的，所以從訂閱到資源群組到服務都已經歸納好比較方便，這次示範標準作法

01.png

圖2. 貼心的可以從最近的資源來選擇(需要的話)

02.png

圖3. 選擇指定訂閱

03.png

圖4. 選擇指定想監視計量的資源群組範圍

04.png

圖5. 選擇指定的服務，列出全部也無法，如果服務不多，方便找即可

07.png

圖6. 指定虛擬機器的網卡

08.png

圖8. 選擇接收的度量

09.png

圖9. 多維度(也可以是不同VM的網卡但同個傳送度量一起比較)同一張網卡選擇傳送的度量

10.png

圖10. 自訂好辨識管理的名稱(不然會把你所有的計量一長串往上加不好管理)

11.png

圖11. 為了想要把不同類型的度量分開，透過新增圖表呈現(可透過不同圖形分開表示)

12.png

圖12. 可以把目前設計好的透過共用功能複製其連結打算給另個管理帳戶來做後續調整設置

13.png

圖13. 把連結複製到無痕瀏覽避免Cookies問題

14.png

圖14. 會跳出登入畫面，改用其他管理帳戶來登

15.png

圖15. 開啟後呈現畫面就跟剛剛設計的一樣，都一樣可以在做邊修

16.png

圖16. 調整完成後就可以釘選至儀表板上

17.png

圖17. 可以再做細部微調包含呈現磚塊大小

18.png

圖18. 開啟自訂磚資料

19.png

圖19. 可以從這邊來決定更新的範圍時間區間

20.png

圖20. 設置完成

22.png