Azure 默认 Reader 与内置监控 Reader
Azure Default Reader vs Built-in Monitoring Reader
我正在尝试设置从安全角度监控数据的最佳角色。我的需求略有不同,所以我不想使用 Security Reader 角色(主要是因为 security reader 只能访问安全中心项目和基本资源和资源组查询)。因此,在阅读更多内容后,我偶然发现了 Monitoring Reader 角色和 Reader 角色。我通过了 JSON 中提到的权限。但是我不确定 JSON.
中是否涵盖了所有差异
例如,当我们谈论“监控 Reader”时
{
"assignableScopes": [
"/"
],
"description": "Can read all monitoring data.",
"id": "/subscriptions/{subscriptionId}/providers/Microsoft.Authorization/roleDefinitions/43d0d8ad-25c7-4714-9337-8ba259a9fe05",
"name": "43d0d8ad-25c7-4714-9337-8ba259a9fe05",
"permissions": [
{
"actions": [
"*/read",
"Microsoft.OperationalInsights/workspaces/search/action",
"Microsoft.Support/*"
],
"notActions": [],
"dataActions": [],
"notDataActions": []
}
],
"roleName": "Monitoring Reader",
"roleType": "BuiltInRole",
"type": "Microsoft.Authorization/roleDefinitions"
}
权限基本一样,就是可以查询日志。与 Reader 角色相比
{
"assignableScopes": [
"/"
],
"description": "Lets you view everything, but not make any changes.",
"id": "/subscriptions/{subscriptionId}/providers/Microsoft.Authorization/roleDefinitions/acdd72a7-3385-48ef-bd42-f606fba81ae7",
"name": "acdd72a7-3385-48ef-bd42-f606fba81ae7",
"permissions": [
{
"actions": [
"*/read"
],
"notActions": [],
"dataActions": [],
"notDataActions": []
}
],
"roleName": "Reader",
"roleType": "BuiltInRole",
"type": "Microsoft.Authorization/roleDefinitions"
}
现在从逻辑的角度来看,如果两个用户都能够执行 */read
,Reader 角色是否自动有资格查询日志?如果不是,那有什么不同?还有哪个角色在访问可读数据方面更胜一筹?
参考:https://docs.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#reader
PS : 我知道自定义角色,但想更好地了解内置角色。
Now from a logical standpoint if both the users are able to execute */read doesn't Reader role automatically qualify to query the logs?
他们都可以执行*/read
,但是Reader
不能查询日志。
If not, how is it different?
区别是Monitoring Reader
可以执行Microsoft.OperationalInsights/workspaces/search/action
和Microsoft.Support/*
动作。
Also which role is superior in terms of access to readable data?
从角色定义的 actions
范围来看,显然 Monitoring Reader
在访问可读数据方面更胜一筹。
我正在尝试设置从安全角度监控数据的最佳角色。我的需求略有不同,所以我不想使用 Security Reader 角色(主要是因为 security reader 只能访问安全中心项目和基本资源和资源组查询)。因此,在阅读更多内容后,我偶然发现了 Monitoring Reader 角色和 Reader 角色。我通过了 JSON 中提到的权限。但是我不确定 JSON.
中是否涵盖了所有差异例如,当我们谈论“监控 Reader”时
{
"assignableScopes": [
"/"
],
"description": "Can read all monitoring data.",
"id": "/subscriptions/{subscriptionId}/providers/Microsoft.Authorization/roleDefinitions/43d0d8ad-25c7-4714-9337-8ba259a9fe05",
"name": "43d0d8ad-25c7-4714-9337-8ba259a9fe05",
"permissions": [
{
"actions": [
"*/read",
"Microsoft.OperationalInsights/workspaces/search/action",
"Microsoft.Support/*"
],
"notActions": [],
"dataActions": [],
"notDataActions": []
}
],
"roleName": "Monitoring Reader",
"roleType": "BuiltInRole",
"type": "Microsoft.Authorization/roleDefinitions"
}
权限基本一样,就是可以查询日志。与 Reader 角色相比
{
"assignableScopes": [
"/"
],
"description": "Lets you view everything, but not make any changes.",
"id": "/subscriptions/{subscriptionId}/providers/Microsoft.Authorization/roleDefinitions/acdd72a7-3385-48ef-bd42-f606fba81ae7",
"name": "acdd72a7-3385-48ef-bd42-f606fba81ae7",
"permissions": [
{
"actions": [
"*/read"
],
"notActions": [],
"dataActions": [],
"notDataActions": []
}
],
"roleName": "Reader",
"roleType": "BuiltInRole",
"type": "Microsoft.Authorization/roleDefinitions"
}
现在从逻辑的角度来看,如果两个用户都能够执行 */read
,Reader 角色是否自动有资格查询日志?如果不是,那有什么不同?还有哪个角色在访问可读数据方面更胜一筹?
参考:https://docs.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#reader
PS : 我知道自定义角色,但想更好地了解内置角色。
Now from a logical standpoint if both the users are able to execute */read doesn't Reader role automatically qualify to query the logs?
他们都可以执行*/read
,但是Reader
不能查询日志。
If not, how is it different?
区别是Monitoring Reader
可以执行Microsoft.OperationalInsights/workspaces/search/action
和Microsoft.Support/*
动作。
Also which role is superior in terms of access to readable data?
从角色定义的 actions
范围来看,显然 Monitoring Reader
在访问可读数据方面更胜一筹。