沒有密碼，才是最安全的密碼 - 使用 DefaultAzureCredential()

作者： DD - 7月 19, 2026

古時候

好久好久以前，在遙遠的開發國度中，程式設計師在撰寫應用程式時，常會把資料庫連線字串、API Key、帳號密碼或其他設定，直接放在程式碼裡面。

例如：

string connectionString =
    "Server=myserver;Database=mydb;User Id=admin;Password=P@ssw0rd;";

這樣做很方便，程式下載下來、編譯、執行，馬上就可以連線。

但問題也很明顯：只要程式碼被上傳到 Git Repos，或是被複製到其他地方，裡面的帳號密碼也會一起被帶走。

而且，即便 Repository 是 Private，也不代表這些敏感資訊就是安全的。

因為能夠讀取 Repository 的人、包含CI/CD Pipeline、第三方掃描工具、AI Coding Agent，都可能接觸到這些內容。

因此，大多數開發人員都知道：

不要把帳號密碼直接寫在程式碼裡。

於是，大家就把它移到設定檔裡。🤔(是不是哪裡怪怪的?)

例如 .NET 的 appsettings.json 或 web.config：

{
  "ConnectionStrings": {
    "DefaultConnection": "Server=myserver;Database=mydb;User Id=admin;Password=P@ssw0rd;"
  }
}

或是 Python 常見的 .env：

DB_CONNECTION_STRING=Server=myserver;Database=mydb;User Id=admin;Password=P@ssw0rd;

這樣比把密碼寫在程式碼裡好嗎?
是的，至少在『心理上』稍微好了一點。因為帳號密碼是存在某個可以被替換的檔案裡。

但是這個檔案依舊可能會：

不小心被 Commit 到 Repository
被複製到測試環境或其他電腦
出現在部署封裝或 Container Image 裡
被寫進 CI/CD Pipeline 的 Log
…

更麻煩的是，一旦密碼需要更換(資安規定90天要Roatate)，我們就必須找出所有使用這組密碼的程式、環境與設定檔，再逐一更新。

因此，真正解決這個問題的方式根本不是問：

密碼應該放在哪裡？

而是：

應用程式能不能根本不要持有密碼？

當然可以，且2026年的現在你也該開始這麼做了。
在 Azure 中，實現這件事情最典型的做法就是透過底下這些方案：

Microsoft Entra ID
Azure RBAC
Managed Identity

讓開發人員與應用程式都透過「身分」取得存取資源的授權，而不是透過帳號密碼或是 Access Key。

具體該怎麼做?

我們舉個例子來說，假設我們的網站程式碼要存取 Azure 當中的 App Configuration 服務(如果你對這服務沒概念，就想成存取SQL Server吧)，過去存取的方式是在程式碼設定檔當中撰寫連線字串，然後區分開發環境和正式環境，讓它有所不同。

但這樣，我們的帳密就有可能會暴露，因此，現在我們打算不要在程式碼當中撰寫任連線字串和帳密，但讓程式依舊可以安全的存取App Configuration(或資料庫、或blob、或其他資源)。

這該怎麼做?

我們可以採用 Azure 的 RBAC。

什麼是 Azure RBAC？

RBAC 是 Role-Based Access Control，也就是「角色型存取控制」。

它的概念並不複雜。

我們不是直接把某個 Access Key(帳密、或連線字串) 交給使用者或寫在程式中，而是告訴 Azure：

哪個身分，可以對這個資源做哪些事情。

一個 RBAC Role Assignment 通常包含三個部分：

誰（Security Principal）
    +
具有什麼角色、可以做什麼（Role）
    +
在哪個範圍內（Scope）

例如：

開發人員 (abc@studyhsot.com)
    +
具有 App Configuration Data Reader 身分(可以 Read)
    +
ConfigData1(App Configuration 中的某個 Key)

意思就是：

abc@studyhsot.com 這個使用者，可以 讀取 App Configuration 中的ConfigData1 裡面的設定資料。

Azure RBAC 可以將角色授予特定使用者(我喜歡稱之為自然人)、群組、Service Principal(我喜歡稱之為法人) 或 Managed Identity(待會再特別說說它)，並且可以在 Subscription、Resource Group 或特定雲端資源…等不同的 Scope 上指派。

拿我們剛才提到的 Azure App Configuration 來說的話，常用的資料存取角色有：

而我們佈署應用程式的網站，因為只需要讀取設定(Configration Data)，因此應該使用：

App Configuration Data Reader

這個 Role 就夠了。不能因為方便就直接授予 Data Owner權限，這也是最小權限原則的基本概念。

什麼是 Managed Identity(受控識別)？

在本機開發環境中，執行程式的人是開發人員。

所以程式在開發環境運行時，使用的是開發人員的帳號，例如我們剛才的：

abc@studyhsot.com

但是，當網站部署到 Azure 雲端的 Web App 之後，是用誰的身分在執行程式？

當然不是開發人員本人。

這時候，我們可以替 Azure Web App 啟用 Managed Identity：

Managed Identity 可以理解成：

Azure 自動替這個 Web App 建立及管理的一個 Microsoft Entra 身分。(也就是應用程式註冊)

這個身分不是一般使用者(不是自然人，而是法人)，不需要我們替它建立密碼，也不需要把 Client Secret 放進設定檔。

Azure 會替我們管理這個身分所需要的認證資訊與生命週期。(可以想成傳統地端環境的 services account)

啟用 Managed Identity 後，我們就可以把特定的RBAC Role 指派給這個 Web App。

例如：

my-web (Managed Identity)
    +
App Configuration Data Reader
    +
ConfigData1

如此一來，網站本身就能以自己的身分讀取 App Configuration 服務中的 ConfigData1 資料，我們只需要在 Azure 資源的 IAM 中統一進行設定即可。

那開發階段呢?

最重要的部分：DefaultAzureCredential

在本機開發時，你一樣可以透過 RBAC 的方式，先為開發人員帳號(例如abc@studyhsot.com)設定其具有存取雲端資源的身分。

然後，開發人員可以在開發環境使用底下這幾種方式之一登入：

Azure CLI 登入的帳號(az login)
Visual Studio 登入的帳號
Azure Developer CLI 登入的帳號
環境變數中設定的 Service Principal

接著，只要在程式碼中撰寫底下的指令來進行連線：

new DefaultAzureCredential()

就可以直接存取到特定的雲端資源。
沒錯，不用帳密。

而部署到 Azure Web App 後，它就會自動替換成使用前述的Managed Identity + RBAC 的方式存取資源。

如此一來，無論是開發階段或測試、正式階段，程式碼中(包含設定檔)都完全不用保存任何的帳密資料。

達到真正資訊不落地的安全效果。

底下是 C# 的極簡版範例程式碼片段(連線部分)：

builder.Configuration.AddAzureAppConfiguration(options =>
{
    options.Connect(
        new Uri(appConfigurationEndpoint),
        new DefaultAzureCredential());
});

開發階段運行起來的結果：

佈署到正式環境運行起來的結果：

結論

無論是正式環境，測試環境，程式碼中都沒有任何的帳號與密碼，程式碼也毋須要為了正式或測試環境做任何調整。

不僅安全，也讓開發變得更加便利。

極簡版範例程式碼我放在底下repo:
https://github.com/isdaviddong/AI-200-Managed-Identity-demo

參考課程:
https://www.studyhost.tw/NewCourses/Architecture

搜尋此網誌

.NET Walker