为保证用户日志数据的安全,日志服务 API 的所有 HTTP 请求都必须经过安全验证。
验证流程
目前,该安全验证基于阿里云的访问密钥,使用对称加密算法完成。
其验证流程如下:
- 请求端根据 API 请求内容(包括 HTTP Header 和 Body)生成签名字符串。
- 请求端使用阿里云的访问密钥对(AccessKeyID 和 AccessKeySecret),对第一步生成的签名字符串进行签名,形成该 API 请求的数字签名。
- 请求端把 API 请求内容和数字签名一同发送给服务端。
- 服务端在接到请求后会重复如上的步骤1和步骤2的工作,并在服务端计算出该请求期望的数字签名。
说明 服务端会在后台取得该请求使用的用户访问密钥对。 - 服务端用期望的数字签名和请求端发送过来的数字签名做比对,如果完全一致则认为该请求通过安全验证。否则直接拒绝该请求。
上面的整个流程也可以使用下图描述:
安全验证流程可以达到如下目的:
- 确认哪位用户在做 API 请求。
因为在发送请求前需要用户指定生成数字签名的密钥对,在服务端即可通过该密钥对确定用户身份,进而可做访问权限管理。
- 确认用户请求在网络传输过程中有无被篡改。
因为服务端会对接收到的请求内容重新计算数字签名,一旦请求内容在网络上被篡改,则无法通过数字签名比对。
签名 API 请求
为了通过 API 请求的安全验证,用户需要在客户端对其 API 请求进行签名(即生成正确的数字签名),并且使用 HTTP 头 Authorization 在网络上传输该请求的数字签名。Authorization
头的具体格式如下:
Authorization:LOG <AccessKeyId>:<Signature>
如上格式所示,Authorization 头的值包含用户访问密钥对中的 AccessKeyId,且与之对应的 AccessKeySecret 将用于 Signature
值的构造。下面将详细解释如何构造该 Signature 值。
请求签名过程示例
为了帮助您更好地理解整个请求签名的流程,我们用两个示例来演示整个过程。首先,假设您用做日志服务 API 签名的访问密钥对如下:
AccessKeyId = "bq2sjzesjmo86kq*********"
AccessKeySecret = "4fdO2fTDDnZPU/L7CHNd********"
- 示例一
您需要发送如下 GET 请求列出 ali-test-project 项目下的所有 Logstore,其 HTTP 请求如下:
GET /logstores HTTP 1.1 Mon, 09 Nov 2015 06:11:16 GMT Host: ali-test-project.regionid.example.com x-log-apiversion: 0.6.0 x-log-signaturemethod: hmac-sha1
如上 Log Service API 请求生成的签名字符串为:
GET\n\n\nMon, 09 Nov 2015 06:11:16 GMT\nx-log-apiversion:0.6.0\nx-log-signaturemethod:hmac-sha1\n/logstores?logstoreName=&offset=0&size=1000
由于是 GET 请求,该请求无任何 HTTP Body,所以生成的签名字符串中 CONTENT-TYPE 与 CONTENT-MD5 域为空字符串。如果以前面指定的
AccessKeySecret 做签名运算后得到的签名为:jEYOTCJs2e88o+y5F4/S5IsnBJQ=
最后发送经数字签名的 HTTP 请求内容如下:
GET /logstores HTTP 1.1 Mon, 09 Nov 2015 06:11:16 GMT Host: ali-test-project.regionid.example.com x-log-apiversion: 0.6.0 x-log-signaturemethod: hmac-sha1 Authorization: LOG bq2sjzesjmo86kq35behupbq:jEYOTCJs2e88o+y5F4/S5IsnBJQ=
- 示例二
您需要给同上例 ali-test-project 项目中名为 test-logstore 的 Logstore 写入下面的日志:
topic="" time=1447048976 source="10.10.10.1" "TestKey": "TestContent"
为此,按照 Log Service API 定义需要构建如下 HTTP 请求:
POST /logstores/test-logstore HTTP/1.1 Date: Mon, 09 Nov 2015 06:03:03 GMT Host: test-project.regionid.example.com x-log-apiversion: 0.6.0 x-log-signaturemethod: hmac-sha1 Content-MD5: 1DD45FA4A70A9300CC9FE7305AF2C494 Content-Length: 52 x-log-apiversion:0.6.0 x-log-bodyrawsize:50 x-log-compresstype:lz4 x-log-signaturemethod:hmac-sha1 <日志内容序列化成 ProtoBuffer 格式的字节流>
在这个 HTTP 请求中,写入的日志内容首先被序列化成 ProtoBuffer 格式(请参见ProtoBuffer格式了解该格式的更多细节)后作为请求 Body。所以该请求的 Content-Type 头的值指定为 application/x-protobuf。类似,Content-MD5
头的值是请求 body 对应的 MD5 值。按照上面的签名字符串构造方式,这个请求对应的签名字符串为:POST\n1DD45FA4A70A9300CC9FE7305AF2C494\napplication/x-protobuf\nMon, 09 Nov 2015 06:03:03 GMT\nx-log-apiversion:0.6.0\nx-log-bodyrawsize:50\nx-log-compresstype:lz4\nx-log-signaturemethod:hmac-sha1\n/logstores/test-logstore
同样,以前面示例中的 AccessKeySecret 做签名运算,得到的最终签名为:
XWLGYHGg2F2hcfxWxMLiNkGki6g=
最后发送经数字签名的 HTTP 请求内容如下:
POST /logstores/test-logstore HTTP/1.1 Date: Mon, 09 Nov 2015 06:03:03 GMT Host: test-project.regionid.example.com x-log-apiversion: 0.6.0 x-log-signaturemethod: hmac-sha1 Content-MD5: 1DD45FA4A70A9300CC9FE7305AF2C494 Content-Length: 52 x-log-apiversion:0.6.0 x-log-bodyrawsize:50 x-log-compresstype:lz4 x-log-signaturemethod:hmac-sha1 Authorization: LOG bq2sjzesjmo86kq35behupbq:XWLGYHGg2F2hcfxWxMLiNkGki6g= <日志内容序列化成ProtoBuffer格式的字节流>
原创文章,作者:网友投稿,如若转载,请注明出处:https://www.cloudads.cn/archives/33836.html