我正在寻找一种身份验证机制,允许根据客户端的域名强制执行访问策略。身份验证服务器使用 DNS 中可用的信息来验证客户端授权。
更多细节:
访问策略 资源所有者将资源访问权限限制在特定子域(例如 my-x-service.clientexample.com)。要访问资源,客户端必须证明其拥有子域,或者证明其是代表域所有者授权访问该资源的第三方。
验证 为了证明其代表域所有者行事,客户端必须将其 IP 地址列入域名的 TXT 记录白名单。身份验证服务器将客户端请求的 IP 地址与所声明域的 TXT 记录上发布的列表进行匹配。如果两者匹配,则授予对资源的访问权限。
http://maps.serverexample.com/getLocationByname?params
Content-Type: application/JSON
Claim-Domain: my-x-service.clientexample.com
是否已经存在这样的标准?我只知道 SPF,但由于它用于电子邮件,我认为规范需要进行一些调整。
编辑 -
答案1
SPF 不是安全凭证
我认为这里最大的误解是 SPF 记录提供了可信凭证。事实上,SPF 是不是一个安全的凭证,至少在现实世界的安全中是如此。
DNS 本质上是一种不安全的协议。它基于 UDP(无传输层握手),协议本身不实现握手,并且没有加密保证您收到的“回复”数据包没有被欺骗。如果您进行一些研究,您会发现这种情况随处可见。
房间里的大象非常明显:如果 DNS 如此不安全,为什么 SPF 可以这样做?因为风险很低。SPF 可能发生的最坏情况是零收益情况:如果您没有 SPF 记录,您将回到原来的状态。SPF 是一个丑陋的妥协,邮件管理员在面对更大的问题时被迫采取这种妥协,这就是它的全部。
为了进一步研究,我建议您研究一种鲜为人知的 DNS 记录类型,称为SSHFP
以及它面临的挑战。SSHFP
是将服务器的 SSH 公钥放入 DNS 的标准。您的 SSH 客户端永远不会要求您最初信任密钥。那将是极好的。但是,如果您研究SSHFP
SSH 客户端信任记录的先决条件,就会发现它与此处描述的问题类型完全相同。这应该可以消除任何关于 DNS 是否可以在没有某种形式的根名称服务器信任的情况下提供安全凭证的疑虑。(DNSSEC)
DNS 安全并不是唯一的挑战
好的,现在你知道你所描述的原因了没有以前就有人做过。不过 DNSSEC 马上就要来了,对吧?让我们假设每个人都可以使用验证 DNSSEC 解析器,并且 DNSSEC 不会像 IPv6 那样面临同样的惰性。
这个标准可能不会实现。
我知道 Mark 的回答附带的评论不是你想听到的,但他们说发布可信 IP 列表是个坏主意,这一点说得很对。大公司将会非常不鼓励实施三步信任,即向互联网发布可用于访问其系统的 IP 列表。这对他们来说是一个荒谬的前景,特别是当公钥加密存在并且是管理委托信任系统的首选方式时。
在这个答案中我提到过二这些技术可以解决影响全球 IT 领域所有人的更大问题,而这两者都面临着巨大的惯性。与让这只鸟飞起来相比,这种惯性微不足道。这是该死的真理。
答案2
想想这是如何工作的。SPF 之所以有效,是因为它允许偏僻的邮件服务器验证其收到的邮件,以确保邮件确实来自其应发送的地方。这让发件人首先要有 SPF 记录。
这如何与用于 Web 访问的 DNS 记录配合使用?它会发布允许连接到它的客户端列表,然后……会发生什么?然后客户端会说“哦不!我不在列表中!我最好断开连接!”,没有人曾经一位不遵守这些记录的客户写道。没有人需要在晚上锁门,我们不需要银行,因为我们把钱放在床底下的鞋盒里,警察部队退休了,因为每个人都开始相处融洽,世界和平不再是一个不切实际的梦想。
如果您希望所有者将资源限制在已知的 IP 地址,请按照几十年来一直使用的方式进行:使用防火墙。或者按照几乎同样长期使用的方式进行:使用 Web 服务器配置规则。
答案3
资源所有者限制对一个或多个域名的访问。
我能想到的最接近此的做法是运行所有自己的名称服务器,并使用 ACL 来限制谁有权限查询给定区域。
示例配置摘录(用于绑定):
acl trusted_src_ip {
192.168.2.0/24;
2001:db8::/64;
};
zone "mysecretdomain.com" IN {
type master;
file "zones/mysecretdomain.com";
allow-query { trusted_src_ip; };
};
但这几乎肯定是针对您要解决的实际问题的错误解决方案。