Abstract: Log audit is the core part of information security audit function and an important part of enterprise information system security risk control. SLS log audit service provides one-stop log collection, storage, query, visualization and warning capabilities for various cloud products of Ali Cloud (ActionTrail, OSS, SLB, RDS, POLARDB, SAS, WAF, etc.), which can be used to support common application scenarios such as security analysis and compliance audit.

The background,

Introduction to Log Audit

Log audit is the core part of information security audit function and an important part of enterprise information system security risk control. SLS log audit service provides one-stop log collection, storage, query, visualization and warning capabilities for various cloud products of Ali Cloud (ActionTrail, OSS, SLB, RDS, POLARDB, SAS, WAF, etc.), which can be used to support common application scenarios such as security analysis and compliance audit.

Features of log audit: • Centralized collection • Cross-account: Support to collect logs from multiple primary accounts into a Project under one primary account. • One-click collection: After the collection policy is configured at one time, new resources (such as newly created RDS, SLB, OSS Bucket instance, etc.) can be automatically discovered across accounts in real time and logs can be collected in real time. • Centralized storage: the collected logs are stored in a centralized Project in a certain region to facilitate follow-up query analysis, visualization, warning, secondary development, etc. • Support rich audit functions • Inherit all the existing functions of the log service, including query analysis, processing, reporting, warning, export and other functions, to support the needs of centralized audit in the audit scenario. • Ecological open docking: seamless docking with open source software, Ali Cloud big data products and third-party SoC software to give full play to the value of data.

Log audit service provides a unified management interface, which is convenient for users to collect and configure cloud product logs. This page provides functions such as collection switch, storage mode (regionalization/centralization), TTL, and whether to turn on threat intelligence detection for various cloud products.

Permission issues faced by enterprises on the cloud

As we all know, the master account has the ownership of all the resources under the account, and you can modify the configuration of all the resources under the account. After the enterprise is on the cloud, especially in the scene where multiple departments or business lines of a company are developing, if the main account is used for operation, the risk is very high. RAM, on the other hand, provides a simple security resource control system for enterprises to solve the above problems by uniformly allocating permissions and centrally controlling resources.

Some common rights control problems faced by enterprises after entering the cloud:

• There is multi-user cooperative operation, RAM users have different division of labor, each performing its own duties. • The cloud account does not want to share the cloud account key with other RAM users. The risk of key leakage is large. • RAM users can access resources in a variety of ways and are at high risk of resource leakage. • Some RAM users need to revoke their access to resources when they leave the organization.

After an enterprise goes to the cloud, it can achieve the purpose of authority control by creating and managing RAM users and controlling the operation authority of these RAM users on resources (the principle of minimum authority allocation). As the control center of cloud log security audit, log audit service is the configuration entrance of cloud log compliance, so security is of great importance. Similarly, we can also use RAM reasonably to achieve access control purposes.

Log auditing best practices

To take advantage of RAM to access control log audit services, you first need to clear the log audit scenario involves resources: • log audit APP, https://sls.console.aliyun.co… • Resources under the Project where the audit logs are stored, including Project, Logstore, index, report, data processing tasks, etc. SLSAUDIT-CENTER -${uid}-${region} SLSAUDIT -REGION -${uid}-${region} -${region} Access: SLSAUDIT -REGION -${uid}-${region} Access: • Usage scenarios: Direct use is not recommended. • Subaccounts with log audit write permissions (first opened) : • Permission: • System permission policy: AliyunRAMFullAccess/AliyunSTSAssumeRoleAccess, used to automatically create the audit need built-in role SLS – audit – service – dispatch, the SLS – audit – service – monitor. • Minimum permission for custom log audit write: you need to have the permission to view and configure the log audit APP, so you can view the data under the log audit project. • Usage scenario: Log auditing can be first enabled and subsequent configuration changes can be made. Son, have write permissions log audit accounts (not open) for the first time: • permissions: • system permissions strategy: AliyunRAMReadOnlyAccess/AliyunSTSAssumeRoleAccess. • Minimum permission for custom log audit write: you need to have the permission to view and configure the log audit APP, so you can view the data under the log audit project. • Usage scenario: After log auditing is enabled, configuration changes related to log auditing can be made. • has read-only access log audit child accounts: • permissions: • system permissions strategy: AliyunRAMReadOnlyAccess/AliyunSTSAssumeRoleAccess. • Custom log audit read-only minimum permission: you need to have the view permission of the log audit APP to view the data under the log audit project. • Usage scenarios: For developers with general permissions. You can only view the log audit configuration, and the data in the Project.

Minimum permission of RAM sub-account log audit operation

1, custom log audit write minimum permission

{
    "Version": "1",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "log:GetApp",
                "log:CreateApp"
            ],
            "Resource": [
                "acs:log:*:*:app/audit"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "log:Get*",
                "log:List*",
                "log:CreateJob",
                "log:UpdateJob",
                "log:CreateProject"
            ],
            "Resource": [
                "acs:log:*:*:project/slsaudit-*"
            ]
        }
    ]
}

2, The minimum read-only permission of custom log audit is compared with the minimum permission of custom log audit write, and the permissions of “log: createApp “, “log:CreateJob”, “log:UpdateJob”, and “log:CreateProject” are removed.

{
    "Version": "1",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "log:GetApp"
            ],
            "Resource": [
                "acs:log:*:*:app/audit"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "log:Get*",
                "log:List*"
            ],
            "Resource": [
                "acs:log:*:*:project/slsaudit-*"
            ]
        }
    ]
}

Four, operation steps

1. Create the permissions mentioned in Part 3

For example, create a permission policy named AUDIT_TEST.

2. Authorize sub-accounts according to the permission list in Part II

3. Log in the sub-account for auditing

Five, through the permission of negative control

The “Minimum Permission for RAM Subaccount Log Auditing” mentioned in the third part of this article aims to limit subaccount permissions as much as possible. However, in some scenarios, the child account would like to have large permissions on SLS, but it needs to exclude the logging audit APP configuration permissions. In this case, it needs to use RAM permission denial function. The detailed permission configuration is as follows:

{
  "Version": "1",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": [
        "log:CreateApp"
      ],
      "Resource": [
        "acs:log:*:*:app/audit"
      ]
    },
    {
      "Effect": "Deny",
      "Action": [
        "log:CreateJob",
        "log:UpdateJob",
        "log:CreateProject"
      ],
      "Resource": [
        "acs:log:*:*:project/slsaudit-*"
      ]
    }
  ]
}

For example, if a child account is granted AliyunLogFullAccess, the child account will have all SLS privileges. However, when you want to take back the audit APP configuration permission, you can add a custom negation policy.



The original link

This article is the original content of Aliyun, shall not be reproduced without permission.