原文發表於 Next Generation Cryptography now available with Azure Web Sites。

沒有什麼事情，比使用 SSL 來提升您網站的安全性來得更重要了，然而，即使加密不是什麼新的技術，密碼學家仍然不斷地尋找能讓加密技術更安全的作法。而我們 Azure 網站服務團隊也一直不斷地支援最新最安全的加密運算，今天要跟各位介紹我們已經支援很棒、使用橢圓曲線加密法（ECC, Elliptic Curve Cryptography）的憑證。

橢圓曲線加密技術，是基於在有限場（finite field）中橢圓曲線的代數結構，聽不懂了嗎？別擔心，很多人都聽不懂這玩意兒。要畫出橢圓曲線的圖，都是根據 y² = x³ + ax + b 這個代數方程式，當你將 X 及 Y 對應的值畫出來時，你會發現它是一個對稱的橢圓曲線，舉例來說，若是畫出 y²=4x³-4x+4 這個代數方程式，就會像下面這張圖一樣：

為了不讓這篇文章變成艱深的數學課，我們簡單地說，當一個代數方程式有這樣複雜且對稱性質，那就可以用來產生一個函數，有效地產生不容易攻破的公鑰（public key）及私鑰（private key）來做加解密。我們先產生一把私鑰，選定一個橢圓曲線來產生出對應的公鑰，要從公鑰反推回私鑰（也就是我們俗稱的攻擊、破解）是出了名地難，而且運用當今科技也無法在合理的時間內破解成功，這個方式相較於現在常見的一些公鑰私鑰加解密系統大概可以提升 10 倍以上的難度（確定你真的想瞭解為什麼，再讀這篇文章），換句話說，使用 256 位元的橢圓曲線加密法，它的安全指數相當於使用 2600 位元的 RSA 加密法，而現今業界常使用的標準不過是 2048 位元的 RSA 加密法，這已經是很難攻破的加密法了，由此可知，若使用相同位元的橢圓曲線加密法，要用現在的超級電腦破解它簡直是天方夜譚。

說了這麼多，我們只是想讓您知道，現在您不只可以購買市面上常見的 SSL 憑證，還可以購買更安全、使用 ECC 的 SSL 憑證來確保您網站服務的安全性。ECC 憑證目前還是一項很新的技術，市場上還沒有很多家業者有提供，不過若您有需要，現在可以向 Symantec 或是 Entrust 來購買，不過相信很快很多憑證業者就會跟進了。

你知道嗎？Azure 網站服務最近已經通過 ECC 憑證的測試了！所以您也可以在 Azure 網站服務上安裝 ECC 憑證，就跟過去安裝憑證一樣，上傳您購買的 .pfx 憑證檔案就可以立即運作了！不過要注意的是，不是所有的用戶端都支援 ECC 憑證，但如果您是使用 Windows Vista 之後的電腦，那就可以不必經過特殊設定，也能使用瀏覽器來瀏覽使用 ECC 憑證做 SSL 加密的網站！

自 2014 年4月7日 OpenSSL 代號 Heartbleed (CVE-2014-0160) 資安漏洞公告後，陸續又發布了數項其它資安漏洞 (http://www.openssl.org/news/vulnerabilities.html)，許多客戶都欲了解這幾次資安漏洞是否會影響微軟的產品，特別是 Microsoft Azure。Microsoft Azure 與大多數 Microsoft 服務是使用微軟公司實作之 Windows SSL/TLS，因此不會受到 OpenSSL 相關資安漏洞的影響。Microsoft Azure Websites 以及 Microsoft Azure Cloud Services Web Role 都未使用 OpenSSL 來實作 SSL 協定，微軟公司使用自己實作之加密元件 Secure Channel (常縮寫為 SChannel) 來支援 SSL 所需的加解密機制。然而 Microsoft Azure Virtual Machines 的用戶可以選擇多種版本之 Linux 作業系統，多數 Linux 作業系統採用 OpenSSL 來提供加密功能，由於 Microsoft Azure Virtual Machines 用戶需要自行維護作業系統相關修補，請用戶關注各 Linux distribution 所發布之相關資安訊息。

原文發佈於 New and improved Azure Status

今天 Microsoft Azure 團隊釋出了新版的 Azure Status （之前是 Service Health Dashboard），現在您可以從 status.azure.com 連這個新的健康狀態儀表板，來確認 Azure 所有服務的服務狀態，而且不必透過身份驗證也能查詢目前在全球各地的 Azure 機房是否有狀況。您也可以訂閱網站所提供的 RSS feed 來關注是否有突發的意外狀況。

注意: 上面的螢幕擷圖並不代表目前的狀態。

目前狀態

在目前狀態（current status）的頁籤中，會秀出目前各服務的狀態、而且問題的層級，頁面上也可能會顯示有什麼突發狀況發生，包括目前可能在進行系統升級，或是服務移轉等等。

這個頁面幾分鐘會自動重整一次，而且您還可以自訂要關注的區域及服務列表，可以完全地個人化使用。

注意: 上面的螢幕擷圖並不代表目前的狀態。

歷史記錄

歷史記錄（history）頁籤能夠讓您瀏覽過去發生過的狀況，以便瞭解我們的系統狀況，當然也是可以自訂篩選何種服務或是哪一個區域的資料中心。

造訪 Azure Status

我們誠摰地邀請您前往新版的 Azure Status 看看、訂閱新的 RSS feed，或是到我們新的論壇來提供寶貴的意見，別忘了更新您的書籤為 status.azure.com 以及舊的 RSS feed（2014/07/14 之後舊的位址就會失效）。

Microsoft Azure Traffic Manager 可以提供用戶跨資料中心之負載平衡或失敗回復 (Failover)，用戶經常詢問 Azure Traffic Manager 失敗回復時偵測端點 (End Point) 的運作方式，到底所設定的主要資料中心端點失效多久後才會切換至備援的資料中心端點? DNS TTL (Time-To-Live) 時間設定成很短有助於縮短停機時間嗎?

針對此類問題 http://msdn.microsoft.com/en-us/library/azure/dn339010.aspx 提供了詳細描述，在此簡述如後。Microsoft Azure Traffic Manager 偵測端點的步驟如下圖:

1. GET – 依據用戶的設定，Azure Traffic Manager 偵測系統會發出 HTTP GET 去偵測端點。
2. 200 OK – 倘若 10 秒鐘內偵測系統收到 HTTP 200 OK 之訊息回覆，代表此一 Azure Cloud Services 或 Azure Websites 端點運作正常。只要是回傳非 HTTP 200 OK 之訊息或超過 10 秒未回應都視為端點偵測到問題。
3. 間隔 30 秒檢查一次 – 偵測系統的檢查動作每 30 秒會執行一次。
4. 系統發生問題，端點無回應 – 倘若在 30 秒偵測間隔中端點發生問題，Azure Traffic Manager 是無法得知的，必須等到下一次偵測檢查才會發現。
5. 確認端點出現問題 (4 次嘗試) – 當 Azure Traffic Manager 偵測系統發送 HTTP GET 而超過 10 秒未獲回應，偵測系統將持續以 30 秒為間格偵測三次，確認端點是否真的停止運作，這意味著 Azure Traffic Manager 至少要花費 1.5 分鐘來確認端點真的已經停止運作， 在連續三次的偵測中若有一次順利在 10 秒內收到 HTTP 200 OK 回應，就視為監測端點已經恢復正常。
6. 標註端點發生問題 – 當連續四次偵測回應都失敗後，Azure Traffic Manager 偵測系統會標註該端點失效。Azure Traffic Manager 對外服務的 domain name 開始啟用備援資料中的端點取代原本這個已經無法運作的端點。
7. 存取出問題端點的用戶流量開始降低 – 終端用戶的流量仍持續前往這個已經無法運作的端點，終端用戶開始感受此服務無法正常運作，由於終端用戶端與輔助 DNS Server 已經緩存 (cached) 了這個無法運作的端點 IP Address，隨著時間推進，DNS Server 逐步更新 domain name 的 IP Address，繼續流向這個無法運作端點的流量會逐漸減少。而 Azure Traffic Manager 監測系統繼續以 30 秒為間隔進行檢查。
8. 出問題端點已經沒有用戶流量 – Azure Traffic Manager DNS TTL 預設時間是 5 分鐘 (300 秒)，因次當超過 DNS TTL 時間後，所有用戶會取得服務端點的新 IP Address，也就是備援資料中心的端點。原本出問題的資料中心端點已經沒有來自終端用戶的流量了。 而 Azure Traffic Manager 監測系統繼續以 30 秒為間隔進行檢查。
9. 出問題端點已經恢復正常，用戶流量開始逐漸增加 – 原本出問題的端點可能在這個時間點恢復正常，但是 Azure Traffic Manager 仍不知道，要等到每 30 秒偵測程序完成後，才會標註系統恢復正常。
10. 用戶流量回到原本資料中心的端點 - 當 Azure Traffic Manager 送出 HTTP GET 並在 10 秒內收到 200 OK 回應後，開始將對外端點切回原本的 DNS name ，當 DNS TTL 時間過後，所有用戶 DNS 緩存內容都會更新回原本主要資料中心的 IP Address， 所有用戶的流量會回到原本的資料中心。

了解 Microsoft Azure Traffic Manager 失敗回復 (Failover) 偵測機制之後，我們可以知道利用此失敗回復的機制而主要資料中心發生問題時，如果使用 DNS TTL 300 秒的預設值，終端用戶至多會感受到 5 分鐘的停機時間，因為 DNS 會緩存已經出問題的 IP Address 直到 DNS TTL 時間超過，而縮短 DNS TTL 時間到 1.5 分鐘以內的意義並不大，因為 Azure Traffic Manager 需要至少 1.5 分鐘的時間連續三次 30 秒間隔的偵測動作來確認端點失效，DNS TTL 過短也會讓 DNS 查詢變得頻繁，而影響系統回應時間。

原文發表於 Azure Web Sites Extensions

每一個 Azure 網站服務（Website）都有一個擴充套件管理服務的功能，讓您可以藉著這個強大的工具部署網站的擴充套件，這些工具涵蓋的範圍很廣，從 Visual Studio Online 的線上編輯器，一直到可以管理網站連接的資源，如：MySQL 資料庫的工具（phpMyAdmin）都有。現在能用的擴充套件可以在 Azure 預覽的新管理介面取得：

您可以參考這個頁面顯示的步驟來為您的網站服務安裝擴充套件，另外您也可以從 Site Extension Gallery http://www.siteextensions.net/ 來上傳擴充套件到您的網站服務之中。

處理既有提供的網站擴充套件

在新的 Azure 預覽管理介面中，您可以在每個網站服務的 Configuration 部份來處理網站擴充套件，打開的畫面會像這樣：

按下 ADD 按鈕後，就可以在清單中選擇要增加的擴充套件，每一個擴充套件下都有註明發佈者的名稱、使用規範等等，安裝之前必須瞭解並且同意使用規範才能繼續。

安裝完畢後，擴充套件會被安裝在 %HOME%\SiteExtensions 目錄下，要注意的是，加入擴充套件後網站會重新啟動以便載入擴充套件。

您可以在安裝的擴充套件列表上，按右鍵或是展開後再選擇不同的按鈕來進行管理

安裝新的擴充套件

您想要建立您自己的擴充套件嗎？我們正努力讓 Azure 的客戶都能自己建立專屬的網站擴充套件。

網站擴充套件（site extension）其實就是一個 Web App 加上一些 metadata 所組成，它可以使用所有 Azure 網站服務所支援的技術（如: ASP.NET, PHP, Python, Node.js, Java）來開發，您可以參考這份文件來瞭解如何開發網站擴充套件，若專案範本沒有建立 applicationHst.xdt 做設定，您可以自行建立，用來設定應用程式以及虛擬目錄的環境。

網站擴充套件會包裝成一個 NuGet 套件格式（參考），您可以從這裡下載 NuGet 命令列工具來打包簡單的套件，也可以從這裡下載這個範例套件的程式碼。

1. 建立一個與擴充套件名稱相同的資料夾。
2. 把 web app 放在資料夾下的 Content 資料夾中。
3. 建立一個 NuSpec 檔案來描述使用規範及版權聲明，可以參考這個檔案。
4. 使用下面的指令打包 NuGet 套件

   nuget pack example.nuspec

您可以在網站擴充套件的入口網站 http://www.siteextensions.net/ 提交一個開發完成的 NuGet 擴充套件，提交前必須註冊一個帳號。

註冊帳號或登入帳號後，就可以進行提交及驗證了

開發 Azure 網站擴充套件可以讓更多 Azure 網站服務受惠，也能讓您獲得成就感，並且隨時可以在擴充套件網站 http://www.siteextensions.net/ 上追蹤有多少人下載安裝您的套件，開發完成也別忘了用力宣傳它！