如何在Azure Automation Runbook中安全验证GitHub Webhook来源？

核心最佳实践推荐 #

• 优先采用HMAC签名验证：这是GitHub Actions原生支持的验证方式，无需额外中间组件，直接在Runbook内完成校验，是当前场景下最轻量化且可靠的方案。GitHub会使用你预设的密钥对请求体进行HMAC-SHA256哈希，将结果放在X-Hub-Signature-256请求头中发送；Runbook只需用相同密钥重新计算请求体的哈希，与请求头中的值对比即可验证来源合法性。
• 网关层防护作为补充（复杂场景）：如果需要更精细化的流量控制（比如速率限制、多来源统一验证），可以将Azure Automation Webhook前置到Azure API Management（APIM）或Azure Function。APIM可通过自定义策略直接完成HMAC验证，拦截非法请求后再转发到Runbook；Azure Function则可以先处理验证逻辑，再调用Runbook，同时还能利用Azure AD身份验证等功能增强防护。
• 不推荐IP白名单：GitHub的出口IP范围动态更新，维护成本极高，且无法完全避免IP伪造类攻击，实际防护效果有限。
• Azure AD令牌验证暂不适用：GitHub Actions难以直接生成符合Azure AD要求的访问令牌，适配成本远高于HMAC方案，不建议作为首选。

Azure内置功能支持 #

• Azure API Management（APIM）：提供现成的HMAC验证策略模板，无需编写大量代码即可在网关层完成请求校验，同时支持IP过滤、请求限流等附加防护，适合多Webhook统一管理的场景。
• Azure Automation Webhook原生密钥：虽然Azure Automation Webhook本身带有唯一的URL密钥，但这仅能防止未授权者猜测URL，无法验证请求来源；结合HMAC验证才能实现完整的身份校验。
• Azure Monitor日志：启用Azure Automation的日志收集后，可记录Webhook请求的详细信息，便于事后审计和异常排查。

PowerShell Runbook中HMAC验证的可行性 #

完全可行，以下是简化的实现示例：

param(
    [Parameter(Mandatory=$true)]
    [string]$RequestHeaderSignature, # 从请求头获取X-Hub-Signature-256的值，格式为sha256=xxxxxx
    [Parameter(Mandatory=$true)]
    [string]$RequestBody,
    [Parameter(Mandatory=$true)]
    [string]$SecretKey
)

# 提取哈希值部分
$signature = $RequestHeaderSignature -replace '^sha256=', ''

# 将密钥和请求体转换为字节数组
$secretBytes = [System.Text.Encoding]::UTF8.GetBytes($SecretKey)
$bodyBytes = [System.Text.Encoding]::UTF8.GetBytes($RequestBody)

# 计算HMAC-SHA256哈希并转换为十六进制字符串
$hmac = New-Object System.Security.Cryptography.HMACSHA256($secretBytes)
$computedHash = $hmac.ComputeHash($bodyBytes)
$computedSignature = [System.BitConverter]::ToString($computedHash) -replace '-', '' | ToLower

# 对比签名
if ($computedSignature -eq $signature) {
    Write-Output "请求验证通过"
    # 执行后续Runbook逻辑
} else {
    Write-Error "请求签名验证失败，拒绝执行"
    exit 1
}

注意：在GitHub Actions工作流中，需将密钥存储在GitHub Secrets中，发送请求时计算并添加X-Hub-Signature-256请求头；Azure Automation中需将密钥作为加密变量存储，避免明文泄露。

内容的提问来源于stack exchange，提问作者Hafiz Mahdi Hasan