فصل ۹ — مدیریت Secrets (اسرار برنامه)

در طول کتاب چند نوع دادهٔ حساس استفاده شد؛ برای مثال Connection String پایگاه داده یا APM. ساده‌ترین راه ممکن این است که این مقادیر در فایل‌های Configuration محیطی مانند appsettings.json، appsettings.dev.json و appsettings.prod.json قرار گیرند و همراه Source Code وارد مخزن Git شوند. اما این روش دو مسئلهٔ جدی ایجاد می‌کند: Secretها کجا و چگونه باید امن ذخیره شوند و چگونه می‌توان آن‌ها را بدون انتشار در Source Code به‌روزرسانی کرد؟

این فصل دو موضوع را پوشش می‌دهد:

• مقدمه‌ای بر مدیریت Application Secret
• نمونهٔ عملی با Azure Key Vault

مقدمه‌ای بر مدیریت Secret

هر فردی که به Source Control دسترسی داشته باشد می‌تواند Secretهای محیط‌های مختلف را مشاهده کند، درحالی‌که مثلاً یک Developer یا Tester الزاماً نباید Password یا Connection String Production را بداند. این موضوع سطح حمله را افزایش می‌دهد و حتی یک عضو داخلی بدخواه نیز می‌تواند تهدید ایجاد کند.

برنامه‌ها خود یکی از نقاط ورودی حمله‌اند. اگر مهاجم به Source Code یا Configuration دسترسی پیدا کند، Secretهایی که دسترسی به Database یا Resourceهای دیگر می‌دهند خطر بسیار جدی خواهند بود. منبع برای نشان دادن اهمیت موضوع به رخداد Uber در سال ۲۰۱۶ اشاره می‌کند که در آن دسترسی غیرمجاز به Secretهای Database به افشای داده‌های میلیون‌ها حساب منجر شد.

برای کاهش چنین ریسکی، نمونهٔ فصل از Azure Key Vault استفاده می‌کند. هدف این فصل آموزش کامل Key Vault نیست، بلکه نشان دادن اصل جداسازی Secret از Source Code است. پیش‌نیاز نمونه یک Key Vault Resource، Vault URI و Azure Tenant ID است.

نمونه با Azure Key Vault

همان منطق را می‌توان برای Connection Stringهای Database، Application Insights یا هر Secret دیگر استفاده کرد. در Key Vault برای هر Secret یک نام و Value ساخته می‌شود؛ نمونهٔ کتاب Secretهای DemoDb1 و DemoDb2 را ایجاد می‌کند.

در سمت ASP.NET Core دو Package نصب می‌شوند:

• Azure.Extensions.AspNetCore.Configuration.Secrets: برای وارد کردن Secretهای Azure Key Vault به Configuration برنامه.
• Azure.Identity: برای Authentication به Azure بدون قراردادن Username/Password مخصوص Key Vault در Source Code و استفاده از Credentialهای محیط توسعه.

Authentication محیط توسعه

در محیط Development، کاربر Visual Studio با همان Microsoft Account مرتبط با Azure احراز هویت می‌شود. DefaultAzureCredential می‌تواند این هویت را در زنجیرهٔ Credentialهای خود استفاده کند.

برای نمونهٔ کتاب Tenant ID به‌صورت Environment Variable با نام AZURE_TENANT_ID در Debug Settings پروژه قرار می‌گیرد.

قرار دادن Vault URI در Configuration

Connection Stringهایی که باید محافظت شوند از appsettings.json حذف می‌شوند. فقط URI خود Key Vault باقی می‌ماند، چون Secret محسوب نمی‌شود:

"KeyVault": {
      "Uri": "{YourKeyvaultUri}"
    }

در صورت تمایل می‌توان حتی این تنظیم را با قابلیت Manage User Secrets از فایل اصلی خارج کرد. Visual Studio در این حالت یک secrets.json محلی می‌سازد. هنگام اجرای پروژه، User Secrets به‌صورت شفاف با Configuration برنامه Merge می‌شود، اما فایل روی ماشین توسعه‌دهنده باقی می‌ماند و نباید به Repository Commit شود.

افزودن Key Vault به Configuration

در Program.cs ابتدا Vault URI خوانده، سپس Key Vault به Configuration اضافه و در پایان Secretها دقیقاً مانند دیگر مقادیر Configuration خوانده می‌شوند.

var builder = WebApplication.CreateBuilder(args);

    ...

    var keyVaultUri = builder.Configuration.GetValue<string>("KeyVault:Uri");
    builder.Configuration.AddAzureKeyVault(new Uri(keyVaultUri),
    new DefaultAzureCredential());
    var dbConnection1 = builder.Configuration.GetValue<string>("DemoDb1");
    var dbConnection2 = builder.Configuration.GetValue<string>("DemoDb2");

    ...

    var app = builder.Build();

    ...

    app.Run();

DefaultAzureCredential در محیط Development از هویتی مانند Microsoft Account واردشده در Visual Studio استفاده می‌کند. در Production سازوکار Credential متفاوت است و معمولاً Cloud Architect یا DevOps یک Service Identity مناسب برای Workload ایجاد می‌کند؛ در نتیجه Password توسعه‌دهنده وارد Production نمی‌شود.

پس از اضافه شدن Provider، Secret با builder.Configuration.GetValue<T>("YourKey") خوانده می‌شود. نام Key باید با Secret ثبت‌شده در Vault مطابقت داشته باشد.

جمع‌بندی فصل

مدیریت ضعیف Secret می‌تواند امنیت کل سامانه را تضعیف کند. Connection String، Password و Credential نباید صرفاً برای راحتی در Source Code یا Repository ذخیره شوند. Azure Key Vault یک نمونه از Secret Store خارجی است؛ در Cloudهای دیگر نیز سرویس‌های مشابه، از جمله AWS Key Management Service، وجود دارند. فصل بعد به جنبهٔ دیگری از امنیت برنامه یعنی Authentication و Authorization می‌پردازد.