.NET Walker

前面 說過，最近因為WFH的關係，協助了一些公司將許多地端的OA相關應用移動到像是Microsoft 365、teams、與Azure等雲端環境上，以確保萬一封城或是台灣大規模分區停電下，企業主要服務依舊可以透過雲端來存取和運行。也因為如此，上次和大家分享了 如何在家裡透過VPN連上Azure ，以安全的方式來存取雲端資源。 但除了讓用戶走VPN去存取雲端資源，以避免讓雲端上的資料或服務公開在網際網路上(讓駭客當箭靶)，另外一個非常基本卻重要的機制，是使用M365/Teams/Azure等雲端服務的企業不該忽略的，也就是2FA(Two-Factor Authentication)。 很多企業用戶可能根本不知道，瀏覽器上常見的登入行為，本身就有機會造成資安疑慮的最大風險，只要用戶在不熟悉的電腦上登入(例如網咖、公用電腦、別人的筆電…)或是用了不熟悉的網路(像是車站、咖啡廳、或是網路上隨意搜尋到的免費WIFI分享網路)，都很可能在無意之間讓你的帳密外洩。 由於Azure和Microsoft 365(包含MS Teams)都是攤在網際網路上的服務，倘若用戶一不小心帳密外洩，那造成的風險恐怕也是不低的。 如何讓帳密更安全嚴謹的使用呢? 答案就是2FA(Two-Factor Authentication)，關於2FA的細節你很容易在網路上找到，這邊就不多提了，總之微軟除了讓用戶以帳密登入以外，還提供你多重的身分驗證機制，例如手機簡訊就是其中之一。 簡單的說，你可以將M365或是Azure帳密設定為 – 在陌生的電腦上登入時，即便正確輸入帳密，還得再透過手機簡訊進行2次驗證(也可以用App進行驗證)。如此一來，可以大幅增加駭客的攻擊難度，避免你在密碼不小心外洩(或被猜對)時，遭受到駭客的入侵。 讓admin開放此功能 設定的方式很簡單，首先，你必須讓M365(Teams)管理員幫你從後台開起這個功能，它位於M365的admin center–>設定–>組織設定–>多重要素驗證： admin可以透過底下UI找到要開啟此功能的用戶，並且點選『啟用』即可： 你會看到底下畫面： 用戶設定2FA驗證(以手機簡訊為例) 啟用之後，下次該用戶成功登入後，就會發信自己被引導到底下畫面： 進入下一步之後，系統會讓你選擇第二重驗證方式： 你可...

在一般的承平時期，企業內部網路要連接到位於雲端的服務，可能會採用 site to site VPN的形式，也就是把企業內網與Azure雲端的虛擬網路透過VPN互聯，達到安全連線的效果： 需求 但最近這幾周，很多企業開始居家上班(WFH)，導致用戶需要從家裡存取雲端上的服務，不管是伺服器、網站、資料庫、或是檔案系統…這時候，該怎麼辦呢? 你可能會說，這很容易啊，位於azure上公有雲的服務，都有對外(對internet)的IP，只要開放讓同仁從家裡連線不就得了? 當然不行，因為如此一來，等於把企業的應用攤在網際網路上讓駭客當箭靶練習入侵，因此，我們還是必須走一個安全的方式才行。 做法有兩種，一個是在企業的防火牆上，開放用戶透過VPN從家裡連線的管道，讓用戶先從家裡連到公司，再從公司透過VPN存取雲端的服務。但這樣等於是透過企業機房作為橋接，大部分公司我猜也是這麼做，但有個小缺點，如果台灣斷電(別跟我說不可能)，那所有的服務就只能停擺了，即便根本沒受影響的雲端服務也是。 因此，另一種作法呢，則是直接讓用戶從家裡以VPN連線到 Azure 雲端服務，直接存取企業在Azure雲端上的資源，如果你根本把整個企業機房(或上面的主要服務)都移上雲端上(做異地備援或主要服務)，更適合這麼作： 這篇文章要介紹的，就是上面這個模式。 如何讓員工，直接透過VPN，從家裡(其實從公司也行)透過網際網路安全的連線到企業位於公有雲上的資源。 環境說明 好，為了說明這個情境，我們建立了一個簡單的模擬。請再仔細看一下上面這張圖，其中有幾個需要注意的部分: 假設企業在雲端有兩台VM(提供了企業的主要應用，先別管是DB還是AP是WEB…反正就是個情境)，IP位置分別是10.0.0.4, 10.0.0.5，這兩台VM使用同一個虛擬網路，其子網路是10.0.0.0/24，這個虛擬網路就是待會我們要讓員工從家裡連上的虛擬網路。 為了讓員工從家裡安全的連上虛擬網路，我們有設置了一個Virtual Network Gateway，員工要從家裡連上虛擬網路，必須通過這個Virtual Network Gateway。 從家裡連上Virtual Network Gateway的工具，是Azure VPN Client，而我們用的驗證方式，是採用Azure AD 驗證，這意味著你必須要有...

『如何在CI/CD Pipeline中發送LINE通知訊息?』有次，Azure DevOps上課時學員問了這個問題。 我聽到之後忍不住說：『這位同學你問得太好了!!!』 耐不住心中竊喜，繼續說道：『本人剛好有 30秒可達成的全球最佳 解決方案。😁』 要知道，關於LINE和Azure DevOps這兩個主題，分開來討論時我也向來是不落人後的，現在這兩個主題合在一起，那我當然就更不客氣了。 開啟Pipeline，我說『請看，第一個步驟，在pipeline中，加入『Use .net core』task： 接著，第二步，上 LINE Notify官網 ，建立一個發訊息給你自己(或群組)的LINE Notify Token： 你會取得一個長得像底下這樣的token: 3QrpcH5XauJVoFCoSxbuWJH747TkC7yW5aXfsDk7RsM 然後，第三步驟，在Pipeline中，加入一個PowerShell Task，在inline script中填入底下指令： dotnet tool install --global line.cli line notify -n 3QrpcH5XauJVoFCoSxbuWJH747TxC7yW5aXfsDk7RsM -m "$(Build.BuildNumber) is done. 狀態: $(Agent.JobStatus)" 然後? 然後就完成了。 現在，你可以自由的在上面這段script中發送訊息給自己(或自己的群組)，當然還可以帶入環境變數$(…)。如此一來，每當CI build完成之後，不管成功或失敗，你都可以即時地取得通知，例如： 這一招，我們採用的是跨平台的 .net core，因此，不管你的build agent是MAC、Linux、還是Windows通通都支援啦😎。 相關課程： 敏捷開發專案管理與Azure DevOps實戰 https://www.studyhost.tw/NewCourses/ALM LINE Bot與人工智慧實戰 https://www.studyhost.tw/NewCourses/LineBot

底下這張圖，看起來頗有學問… 圖片來自MS Azure DevOps AZ-400-1 我們在上DevOps的課程時，第一件事就問同學：在這個大企業林立、變化迅速的時代，新創或台灣的小公司在充滿資源的全球大企業輾壓下，要如何存活? John Boyd的OODA循環帶給我們一個契機，如果你有興趣，可以google一下OODA循環，在wiki百科中的描述如下： OODA循環的理論，來自於美國空軍在韓戰中的經驗。 在韓戰中擔任戰鬥機飛行員的空軍上校約翰·博伊德(John Boyd)認為，美國空軍過於注重速度，在越戰的早期空戰中，這一點就已凸顯出來。而與之形成鮮明對比的是，過時的蘇聯製米格戰鬥機卻在戰場上如魚得水，原因是因為米格機相對容易操作。 在對於競爭型戰鬥機進行了一番詳細分析之後，博伊德的結論是，飛機在空戰中最 關鍵的性能並非絕對速度，而是敏捷度 。在混戰中反應能力最強的戰鬥機能夠繞到敵人身後，隨時準備置敵於死地。 博伊德將其想法總結形成「OODA理論」。 在如今真實世界的挑戰中也是， 最關鍵的性能並非『絕對速度』，而是『敏捷度』 。這是新創和科技公司在最近這20年屢屢戰勝的核心原因。即便大公司擁有更多的資源，但面對挑戰總是輸在自身遲緩的反應上… 因此，DevOps的核心工作，其實是『持續改善，並竭盡所能的縮短你的循環時間(Shorten your cycle time)』。 這些cycle time包含…你修復一個Bug所需要的時間（改善一個錯誤的時間）、你增加一個新功能所需要的時間（在市場上提供新服務的時間）、學習並應用一們新的技術所需要的時間… 而這些縮短且省下的時間，就是你持續改善的所得到的『價值(Value)』，也是企業贏的關鍵。你的『持續改善』(持續縮小cycle time)最終停留在哪一點，你企業(或個人)的限制(瓶頸)就在哪一點出現。 圖片來自MS Azure DevOps AZ-400-1 因此，DevOps追求的是持續改善、持續整合，透過不斷合併與測試，盡早發現缺陷，盡早改善，就是DevOps中CI(continuous integration)做的事情。 面對縮短cycle time的挑戰… 你能多快修復一個bug? 你能多快上版(當然得同時兼顧安全性與品質)? 新功能能夠多快交付到用戶手上? 新構想能夠多...

這一篇很特別，我們要來談談 asp.net (.net core) 的身分驗證類型與基本原理(架構)。 最近這幾年，你可以從網站上找到任何你想找的資訊，特別是程式碼片段，但我總是眼睜睜的看著學員或客戶，從莫名的網路上抄來一份代碼，試著崁入自己的程式，無奈就是怎麼塞都塞不進去，不然就是硬塞進去之後，運行起來不如預期。 原因很簡單，因為硬Copy過來別人寫的東西，我們往往可能根本不知道那段程式碼寫的是什麼，只能硬插，無從改起。 這種狀況這幾年看了不少，身分驗證的部分更加明顯，有同學在寫WebAPI，但卻想用登入畫面去驗證呼叫者身分(!?)，有人明明在寫MVC，卻一直在研究怎麼用JWT Token登入…細問同學為什麼要這麼做? 答案總是很有意思。 所以，一直想寫篇文章，來釐清一下這些東西。 asp.net 網站的身分驗證(保存)類型 asp.net 不管是哪一個版本，不管是 .net framework 或是 .net core，本質上都是一樣的。大部分情境下(這世界總有特例，文章也總是有背景，我們討論的是『大部分』情境下，若有特例，請讀者自行轉換)，伺服器端保留(維持、識別) 用戶身分的機制大概有底下幾種： asp.net的Session變數 aps.net Cookies 驗證 Token (最近好像很流行 JWT) 首先，你必須知道一個前提，所有的Web應用程式和網路上伺服器和用戶端(瀏覽器)之間的交互(資料傳遞、呼叫)行為，本質上都是無狀態的(stateless)，也就是說，你不能假設伺服器端知道用戶是誰，或是伺服器端連續兩次的呼叫是不是由同一位用戶觸發的。 這點跟你的經驗可能不符，你會覺得，網站(伺服器端)知道你是誰啊?不然用戶幹嘛登入? 登入後伺服器端不就知道用戶是誰了嗎? 對，許多的網站都能夠登入，如果是無狀態，那登入怎麼實現的? 好，實現的方式大多是底下這樣，在伺服器端與用戶端溝通(互動)的過程中，會在 http message(大多是header)中，夾帶著一個記號，這個記號具有唯一性，每一個用戶都不同，這個記號隨著網頁每次的來回傳遞(或是WebAPI的被呼叫)，被夾帶在訊息(http message)之間，因此可以讓伺服器端知道當前的用戶端是哪一位。(這個記號大多只是一組ID，用來讓伺服器端識別用戶端，而非在記號...

關於 .net core的登入與身分驗證方式 前情提要… 前幾天，我們示範了如何在 .net core 環境下，使用 cookie-based authentication 來實現登入與身分驗證功能。這個做法是從 .net framework以來就有的，也是延續到 .net core 最簡單且輕量級的身分驗證(登入)方式。 整個作法的影片在底下: https://youtu.be/ag9vQX9GAPs 當然， ASP.NET Core和 ASP.NET Framework 一樣，另外還有一整套 ASP.NET Core Identity機制，這套機制非常完整，除了基本的身分驗證，還包含權限管理、角色(Role)、Token、電子郵件驗證、忘記密碼…etc. 功能繁多。但當然也笨重很多。對於資料庫和身分管理邏輯也有一定程度的相依性。 也因此，我自己比較喜歡 cookie-based authentication 的簡單方法。 而採用了 cookie-based authentication 後的網站，可以透過 C# 後端程式碼，以很簡單的方式透過底下這樣的指令： User . Identity . Name 就可以抓取到當前登入的用戶名稱。詳細的做法，在上面的影片中我們已經初步的介紹了。 cookie-based authentication 搭配 Google 登入 接著，有讀者問到了OAuth的驗證整合，最常見的就是Google 登入。Google登入是什麼呢? 你會看到最近很多網站，都採用Google帳密登入，而非使用網站自己的帳密(也或許是兩者同時)。 所謂的Google 登入驗證，是一種SSO(Single-Sign On)登入機制，採用的其實是一套業界標準的OAuth機制，除了Google以外，Microsoft、Twitter、LINE都有利用這個標準做出了自己的登入功能。相關的說明您可以參考筆者 之前 的介紹。採用這個機制時，網站不需要知道用戶的Google帳密，只需要把身分驗證這一段，丟給Google去作，作完後把結果以Token回傳給網站。 透過Google SSO登入之後，我們可以取得用戶的Token，藉由Token取得用戶的身分(email)，接著，再利用前面介紹過的cookie-based authenti...

透過容器化使用LUIS在地端進行語意分析 應該大家都知道，微軟從幾年前開始，推出了一系列的AI服務，稱為Cognitive Services，內容包含可以識別人臉、辨識圖片內容的電腦視覺，可以即時聽寫(語音轉文字)或輸出(文字轉語音)的Speech API，可以透過類神經網路翻譯的Translator API，還有可以讓chat bot認得用戶輸入的文字的LUIS與QnA…等。 這些服務在雲端上固然方便好用，但每次上課都會有學員問到，可不可以把模型匯出然後在on-premise環境做辨識? 一般會有這種需求不外乎兩個理由，其一是速度，另一個更重要的則是安全性，因為客戶往往不希望要辨識的圖像或文字透過網際網路被傳遞到遠端的伺服器中。 可以嗎? 是的。現在，透過容器化技術，你可以這麼做了。 如今大部分的cognitive services都開始支援容器化的應用方式。我們可以從雲端下載LUIS run-time的image，然後把在雲端上訓練好的模型下載後，透過Container技術在客戶端(用戶端)在on-premise環境做辨識。 怎麼做呢? 其實很簡單。 首先，透過docker command下載雲端上的LUIS run-time(如果在windows上使用，必須安裝好docker desktop)： 完成後，從https://www.luis.ai/網站上把訓練好的luis模型也下載下來： 你應該會下載到一個.gz檔案。 接著建立兩個資料夾，分別是 C:\input 與 C:\output ，用別的路徑當然也可以，後面的docker run指令配合著修改即可。 把剛才下在好的.gz檔案放入 input 資料價，請注意如果需要時要調整檔名，檔名格式為 LUISAppID_PRODUCTION.gz ： 上述都準備完成後，請執行剛才下載的 docker image： 上面docker run指令的格式為： docker run --rm -it -p 127.0.0.1:5000:5000 --memory 4g --cpus 2 ` --mount type=bind,src=c:\input,target=/input ` --mount type=bind,src=c:\out...

WebApp如何安全的存放機密資訊 每一個重要的應用程式裡面都有機密資訊，從資料庫的連線字串，到後台admin的帳號密碼，這些大大小小的機密資訊，常常被開發人員存放在source code的某處…咦? 等等… 對，你應該有所警覺，這些資訊怎麼能存放在程式碼裡呢? 這顯然不夠安全啊。但…直到上周，我在上課的時候，還有學員依舊把連線字串和帳密寫死在程式碼中😮。 那你說，好吧，不寫在程式碼『裡面』，那我獨立寫在一個檔案裡面好了，在 .net 的世界裡，這就是 web.config或是 appsettings.json，但…這樣就安全了嗎? 只能說，『相對』安全了點，但還是不夠安全。 關鍵在於，誰能(或誰該)經手這些機密資訊? 早期的概念是把開發和維運團隊切開，讓開發人員無法得知最終的帳密，讓維運的人無法得知程式碼的內容，這樣，除非這兩個人同時被綁架(或彼此串通)，不然企業的機密資訊還是可以得到保障。有點像是出納和會計不能是同一個人的道理。 這種保護是，不讓『某一個人』知道所有的資訊。只能說相對安全，並非絕對安全，因為經手機密資訊的人還是太多了。安全的定義是， 不該知道的人，就不要知道。 因此，更好的方式是，讓機密資訊只有單一一個安全存放點，且由單一的某一個人寫入。並且，在取用的過程中維持『不落地』。所謂的不落地，就是不儲存在任何地方。簡單的說，就是需要使用時(例如建立資料庫連線)，從安全的存放點取出(帳密)，然後就保存在記憶體中，永遠不寫入任何的檔案、資料庫、硬碟…等儲存體。 真能夠實現這件事情嗎? 可以的。 微軟在Azure雲端上，有一個專門提供存放機密資料的儲存庫，稱為Key Vault(金鑰儲存庫)，管理人員可以把機密資訊(例如admin的帳號密碼、資料庫的連線帳密…etc.)，存放在這個Key Vault中，然後在WebApp的原始程式碼(檔案)中，就不要再存放這些資訊了。當WebApp需要使用的時候，直接問Key Vault拿就可以了： 這樣還有一個莫大的好處，管理人員可以隨時rotate(滾動轉換)帳密資訊，無須開發或維運人員經手。 由於Key Vault是被重重大鎖給保障的(採用高安全性的加密機制)，因此可以說是固若金湯，安全無庸置疑…等…等等，不對啊，那我們的WebApp在存取KeyVaul...