Compartir a través de

Azure Service Fabric 安全

有关 Azure 安全性最佳做法的详细信息,请参阅 Azure Service Fabric 安全性最佳做法

密钥保管库

Azure Key Vault 是建议用于 Azure Service Fabric 应用程序和群集的机密管理服务。

注意

如果将 Key Vault 中的证书/机密以虚拟机规模集机密的形式部署到虚拟机规模集,则必须将 Key Vault 和虚拟机规模集并置。

创建证书颁发机构颁发的 Service Fabric 证书

可以在 Key Vault 中创建或导入 Azure Key Vault 证书。 创建 Key Vault 证书时,私钥在 Key Vault 中创建且不公开给证书所有者。 下面是在 Key Vault 中创建证书的方法:

  • 创建自签名证书,以便创建一个公钥-私钥对并将其与证书相关联。 证书将通过其自身的密钥签名。
  • 手动创建新证书,以便创建一个公钥-私钥对并生成 X.509 证书签名请求。 签名请求可以由注册机构或证书颁发机构进行签名。 签名的 x509 证书可以与挂起的密钥对合并,以便完成 Key Vault 中的 KV 证书。 虽然此方法需要更多步骤,但其安全性更高,因为私钥是在 Key Vault 中创建的,其范围局限于 Key Vault。 下图对此进行了说明。

如需更多详细信息,请参阅 Azure Keyvault 证书创建方法

将 Key Vault 证书部署到 Service Fabric 群集虚拟机规模集

若要将证书从并置的 keyvault 部署到虚拟机规模集,请使用虚拟机规模集 osProfile。 下面是资源管理器模板属性:

"secrets": [
   {
       "sourceVault": {
           "id": "[parameters('sourceVaultValue')]"
       },
       "vaultCertificates": [
          {
              "certificateStore": "[parameters('certificateStoreValue')]",
              "certificateUrl": "[parameters('certificateUrlValue')]"
          }
       ]
   }
]

注意

必须启用保管库才能进行资源管理器模板部署。

将访问控制列表 (ACL) 应用到 Service Fabric 群集的证书

虚拟机规模集扩展发布服务器 Microsoft.Azure.ServiceFabric 用于配置节点安全性。 若要将 ACL 应用到 Service Fabric 群集过程的证书,请使用以下资源管理器模板属性:

"certificate": {
   "commonNames": [
       "[parameters('certificateCommonName')]"
   ],
   "x509StoreName": "[parameters('certificateStoreValue')]"
}

通过公用名保护 Service Fabric 群集证书

若要通过证书 Common Name 来保护 Service Fabric 群集,请使用资源管理器模板属性 certificateCommonNames,如下所示:

"certificateCommonNames": {
    "commonNames": [
        {
            "certificateCommonName": "[parameters('certificateCommonName')]",
            "certificateIssuerThumbprint": "[parameters('certificateIssuerThumbprint')]"
        }
    ],
    "x509StoreName": "[parameters('certificateStoreValue')]"
}

注意

Service Fabric 群集将使用它在主机的证书存储中找到的第一个有效证书。 在 Windows 上,该证书将是具有最晚到期日期且与公用名和颁发者指纹匹配的证书。

Azure 域(例如 *<你的子域>.cloudapp.chinacloudapi.cn 或 <你的子域>.trafficmanager.cn)由 Microsoft 拥有。 证书颁发机构不会将域的证书颁发给未授权的用户。 大多数用户需要从注册机构购买域,或者需要是经授权的域管理员,否则证书颁发机构不会向其颁发具有该公用名的证书。

若要更详细地确定如何配置 DNS 服务,以便将域解析为 Azure IP 地址,请了解如何配置用于托管域的 Azure DNS

注意

在将域名服务器委托给 Azure DNS 区域名称服务器以后,请将下面的两个记录添加到 DNS 区域:

  • 一个适用于域 APEX 的“A”记录,该域不是 Alias record set(对通过解析自定义域得来的所有 IP 地址而言)。
  • 一个适用于你所预配的 Azure 子域的“C”记录,这些子域不是 Alias record set。 例如,可以使用流量管理器或负载均衡器的 DNS 名称。

若要更新门户,以便显示 Service Fabric 群集 "managementEndpoint" 的自定义 DNS 名称,请更新以下 Service Fabric 群集资源管理器模板属性:

 "managementEndpoint": "[concat('https://<YOUR CUSTOM DOMAIN>:',parameters('nt0fabricHttpGatewayPort'))]",

加密 Service Fabric 包机密值

在 Service Fabric 包中加密的常用值包括:Azure 容器注册表 (ACR) 凭据、环境变量、设置,以及 Azure 卷插件存储帐户密钥。

若要在 Windows 群集上设置加密证书并对机密进行加密,请执行以下操作:

生成用于加密机密的自签名证书:

New-SelfSignedCertificate -Type DocumentEncryptionCert -KeyUsage DataEncipherment -Subject mydataenciphermentcert -Provider 'Microsoft Enhanced Cryptographic Provider v1.0'

按照将 Key Vault 证书部署到 Service Fabric 群集虚拟机规模集中的说明操作,将 Key Vault 证书部署到 Service Fabric 群集的虚拟机规模集。

使用以下 PowerShell 命令加密机密,然后使用加密的值更新 Service Fabric 应用程序清单:

Invoke-ServiceFabricEncryptText -CertStore -CertThumbprint "<thumbprint>" -Text "mysecret" -StoreLocation CurrentUser -StoreName My

若要在 Linux 群集上设置加密证书并对机密进行加密,请执行以下操作:

生成用于加密机密的自签名证书:

openssl req -newkey rsa:2048 -nodes -keyout TestCert.prv -x509 -days 365 -out TestCert.pem
cat TestCert.prv >> TestCert.pem

按照将 Key Vault 证书部署到 Service Fabric 群集虚拟机规模集中的说明操作,将 Key Vault 证书部署到 Service Fabric 群集的虚拟机规模集。

使用以下命令加密机密,然后使用加密的值更新 Service Fabric 应用程序清单:

echo "Hello World!" > plaintext.txt
iconv -f ASCII -t UTF-16LE plaintext.txt -o plaintext_UTF-16.txt
openssl smime -encrypt -in plaintext_UTF-16.txt -binary -outform der TestCert.pem | base64 > encrypted.txt

在加密受保护的值以后,在 Service Fabric 应用程序中指定加密的机密,并解密服务代码中加密的机密

在 Service Fabric 应用程序中包含终结点证书

若要配置应用程序终结点证书,请通过将 EndpointCertificate 元素以及主体帐户的 User 元素添加到应用程序清单来添加证书。 默认情况下,主体帐户为 NetworkService。 这将为提供的主体提供应用程序证书私钥 ACL 的管理。

<ApplicationManifest … >
  ...
  <Principals>
    <Users>
      <User Name="Service1" AccountType="NetworkService" />
    </Users>
  </Principals>
  <Certificates>
    <EndpointCertificate Name="MyCert" X509FindType="FindByThumbprint" X509FindValue="[YourCertThumbprint]"/>
  </Certificates>
</ApplicationManifest>

在 Service Fabric 应用程序中添加机密证书

若要让应用程序访问机密,请包括该证书,方法是:将 SecretsCertificate 元素添加到应用程序清单。

<ApplicationManifest … >
  ...
  <Certificates>
    <SecretsCertificate Name="MyCert" X509FindType="FindByThumbprint" X509FindValue="[YourCertThumbprint]"/>
  </Certificates>
</ApplicationManifest>

使用托管服务标识 (MSI) 向 Azure 资源验证 Service Fabric 应用程序

若要了解 Azure 资源的托管标识,请参阅什么是 Azure 资源的托管标识?。 Azure Service Fabric 群集托管在虚拟机规模集上,后者支持托管服务标识。 若要获取可以使用 MSI 向其进行身份验证的服务的列表,请参阅支持 Microsoft Entra 身份验证的 Azure 服务

若要在创建虚拟机规模集期间启用系统分配托管标识,或在现有的虚拟机规模集上这样做,请声明以下 "Microsoft.Compute/virtualMachinesScaleSets" 属性:

"identity": { 
    "type": "SystemAssigned"
}

有关详细信息,请参阅什么是 Azure 资源的托管标识?

如果创建了用户分配的托管标识,请在模板中声明以下资源,以便将其分配到虚拟机规模集。 将 \<USERASSIGNEDIDENTITYNAME\> 替换为你创建的用户分配托管标识的名称:

"identity": {
    "type": "userAssigned",
    "userAssignedIdentities": {
        "[resourceID('Microsoft.ManagedIdentity/userAssignedIdentities/',variables('<USERASSIGNEDIDENTITYNAME>'))]": {}
    }
}

在 Service Fabric 应用程序使用托管标识之前,必须先向该应用程序授予权限,使之能够访问进行身份验证时需要使用的 Azure 资源。 以下命令授予对 Azure 资源的访问权限:

PRINCIPAL_ID=$(az resource show --id /subscriptions/<YOUR SUBSCRIPTON>/resourceGroups/<YOUR RG>/providers/Microsoft.Compute/virtualMachineScaleSets/<YOUR SCALE SET> --api-version 2018-06-01 | python -c "import sys, json; print(json.load(sys.stdin)['identity']['principalId'])")

az role assignment create --assignee $PRINCIPAL_ID --role 'Contributor' --scope "/subscriptions/<YOUR SUBSCRIPTION>/resourceGroups/<YOUR RG>/providers/<PROVIDER NAME>/<RESOURCE TYPE>/<RESOURCE NAME>"

在 Service Fabric 应用程序代码中,通过进行如下所示的 REST 调用获取 Azure 资源管理器的访问令牌

ACCESS_TOKEN=$(curl 'http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https%3A%2F%2Fmanagement.chinacloudapi.cn%2F' -H Metadata:true | python -c "import sys, json; print json.load(sys.stdin)['access_token']")

然后,Service Fabric 应用就可以使用访问令牌向支持 Active Directory 的 Azure 资源进行身份验证。 以下示例介绍如何针对 Azure Cosmos DB 资源执行此操作:

COSMOS_DB_PASSWORD=$(curl 'https://management.chinacloudapi.cn/subscriptions/<YOUR SUBSCRIPTION>/resourceGroups/<YOUR RG>/providers/Microsoft.DocumentDB/databaseAccounts/<YOUR ACCOUNT>/listKeys?api-version=2016-03-31' -X POST -d "" -H "Authorization: Bearer $ACCESS_TOKEN" | python -c "import sys, json; print(json.load(sys.stdin)['primaryMasterKey'])")

Windows 安全基线

我们建议实现广为人知且经过充分测试的业界标准配置,如 Azure 安全基线,而不是自行创建基线;用于在虚拟机规模集上预配这些基线的一个选项是,使用 Azure Desired State Configuration (DSC) 扩展处理程序,以在 VM 处于联机状态时对其进行配置,以便其运行生产软件。

Azure 防火墙

Azure 防火墙是托管的基于云的网络安全服务,可保护 Azure 虚拟网络资源。 它是一个服务形式的完全有状态防火墙,具有内置的高可用性和不受限制的云可伸缩性。;通过此操作,可以将出站 HTTP/S 流量限制到指定的完全限定域名 (FQDN) 列表(包括通配符)。 此功能不需要 TLS/SSL 终止。 建议利用 Windows 更新的 Azure 防火墙 FQDN 标记,并允许到 Microsoft Windows 更新终结点的网络流量流经防火墙。 使用模板部署 Azure 防火墙提供了一个有关 Microsoft.Network/azureFirewalls 资源模板定义的示例。 常用于 Service Fabric 应用程序的防火墙规则是为群集虚拟网络启用以下站点:

  • *download.microsoft.com
  • *servicefabric.cloudapp.chinacloudapi.cn
  • *.core.chinacloudapi.cn

这些防火墙规则是对允许的出站网络安全组的补充,此类安全组将包括 ServiceFabric 和存储,作为来自虚拟网络的允许目标。

TLS 1.2

Azure 建议所有客户迁移到支持传输层安全性 (TLS) 1.2 的解决方案,并确保默认使用 TLS 1.2。

Azure 服务(包括 Service Fabric)已完成工程工作,消除了对 TLS 1.0/1.1 协议的依赖,并为希望将其工作负载配置为仅接受和启动 TLS 1.2 连接的客户提供全面支持。

客户应将其 Azure 托管工作负载以及与 Azure 服务交互的本地应用程序配置为默认使用 TLS 1.2。 下面介绍如何配置 Service Fabric 群集节点和应用程序以使用特定 TLS 版本。

Windows Defender

默认情况下,Windows Defender 防病毒安装在 Windows Server 2016 上。 有关详细信息,请参阅 Windows Server 2016 上的 Windows Defender 防病毒。 用户界面默认安装在某些 SKU 上,但不是必需的。 若要降低 Windows Defender 引发的性能影响和资源使用开销,在安全策略允许排除开源软件的进程和路径的情况下,请声明以下虚拟机规模集扩展资源管理器模板属性,将 Service Fabric 群集排除在扫描范围外:

 {
    "name": "[concat('VMIaaSAntimalware','_vmNodeType0Name')]",
    "properties": {
        "publisher": "Microsoft.Azure.Security",
        "type": "IaaSAntimalware",
        "typeHandlerVersion": "1.5",
        "settings": {
            "AntimalwareEnabled": "true",
            "Exclusions": {
                "Paths": "[concat(parameters('svcFabData'), ';', parameters('svcFabLogs'), ';', parameters('svcFabRuntime'))]",
                "Processes": "Fabric.exe;FabricHost.exe;FabricInstallerService.exe;FabricSetup.exe;FabricDeployer.exe;ImageBuilder.exe;FabricGateway.exe;FabricDCA.exe;FabricFAS.exe;FabricUOS.exe;FabricRM.exe;FileStoreService.exe;FabricBRS.exe;BackupCopier.exe"
            },
            "RealtimeProtectionEnabled": "true",
            "ScheduledScanSettings": {
                "isEnabled": "true",
                "scanType": "Quick",
                "day": "7",
                "time": "120"
            }
        },
        "protectedSettings": null
    }
}

注意

如果不使用 Windows Defender,请参阅有关配置规则的反恶意软件文档。 Linux 不支持 Windows Defender。

在 Service Fabric 群集中托管不受信任的应用程序

根据设计,Service Fabric 群集是单租户,托管应用程序被视为受信任。 因此,应用程序会被授予访问 Service Fabric 运行时的权限,这会通过以下不同的形式表明,例如:环境变量(指向对应于应用程序和 Fabric 文件的主机上的文件路径)、装载在容器工作负载上且具有写入权限的主机路径、进程间通信终结点(接受应用程序特定请求)和客户端证书(Fabric 希望应用程序使用该证书对自身进行身份验证)。

如果你正在考虑托管不受信任的应用程序,必须采取额外的步骤,为 Service Fabric 群集定义和拥有恶意多租户体验。 这将要求你在场景中考虑多个方面,包括但不限于以下方面:

  • 对不受信任的应用程序与其他应用程序、群集本身和基础计算基础结构的交互进行全面的安全审查。
  • 使用适用的最强大的沙盒技术(例如,容器工作负载的适当隔离模式)。
  • 对规避沙盒技术的不受信任的应用程序进行风险评估,因为下一个信任和安全边界是群集本身。
  • 删除不受信任的应用程序对 Service Fabric 运行时的访问权限

RemoveServiceFabricRuntimeAccess

通过在应用程序清单的“策略”部分使用以下声明,可以删除对 Service Fabric 运行时的访问权限:

<ServiceManifestImport>
    <Policies>
        <ServiceFabricRuntimeAccessPolicy RemoveServiceFabricRuntimeAccess="true"/>
    </Policies>
</ServiceManifestImport>

后续步骤