The requirement to separate production and development networks requires not only network separation, but also user separation. This can be controlled through separation of access.

In a cloud environment, there are two ways to grant access, each characterized below.

Role-based access control (RBAC): This is a role-based control of each individual's authorization to access a system.

• Access is controlled by assigning roles to users or groups to which they belong.
• Users control access to resources based on the roles they fall into.

Attribute-based access control (ABAC): This controls who can access a system based on user, resource attributes, and environment.

• It defines attributes to access an object, checks whether the subject trying to access that object has those attributes, and then performs access control.
• Attributes can be anything from the name of the subject to the type of resource, and support varies by service or platform.

Controlling access with ABAC allows for segmented authorizations and reflects different elements of the system, but it requires a lot of time and resources.

RBAC allows for the separation of authorizations for defined roles, so you can grant and revoke authorizations efficiently. That is why we chose to base our authorization separation on RBAC.

In general, developers are not allowed to access production servers. However, there are situations where access is required due to unforeseen events, such as system failures. Also, different operators need different servers and require different authorizations. In this case, you can manage access rights by creating groups for each user and granting authorization according to the group.

Removing file authorization

Before we can use this method, we need to remove the authorization of files that have setuid and setgid set.

When you run a file with setuid applied, your UID becomes the UID of the file owner until the end of the executable. When you run a file as root with setuid applied, your UID becomes root's UID, 0, until the end of the execution, giving you root authorization. Similarly, when you run a file with setgid applied, it becomes the GID of the file's owning group until the end of the executable.

Verification of setuid, setgid files

             find / -user root -type f \( -perm -4000 -o -perm -2000 \) -exec ls -la {} \;

How to take measures

chmod -s [file name]

• If you absolutely need to use a specific setting, there is a way to restrict its use to specific groups. (Restrict setuid usage for general users, only arbitrary groups)

chgrp [group name] [setuid file name]

             chmod 4750 [setuid file name]

In addition, account threshold setting is also required. If you have applied the "Cloud Vulnerability Inspection Guide" published by KISA in 2020, you may already have this security setup in place, but if multiple users are accessing your production servers, it is a good idea to double-check the threshold settings for each account.

             /etc/pam.d/common-auth

               auth required pam_tally2.so onerr=fail even_deny_root deny=5 unlock_time=600

               auth    required    pam_faillock.so preauth silent audit deny=5 unlock_time=600

               # Different OS versions use different versions, so you will need to check the version.

You will also need to set a session timeout. We typically recommend 10 minutes, but you can adjust this based on your company's internal policies.

/etc/profile

             export TMOUT=300

Once you have done that, create authorization groups for each user.

At WhaTap Labs, we have two groups, DevOps Team and Development Team, which can use general commands but are restricted to sudo commands.

Since the WhaTap DevOps Team is controlling the entire operation and handling failures, we did not limit the commands. Since the Development Team is not doing anything other than identifying failures, we only allowed the commands below:

cat, ps, df, du, netstat, curl

We do not allow commands to check logs because the WhaTap monitoring tool is sufficient to check logs, but we do allow cat to check server settings.

1. Create developer group

  groupadd dev      

2. Set group-specific sudo authorizations

        /etc/sudoers

             %dev ALL=NOPASSWD:/usr/bin/cat, /usr/bin/ps, /usr/bin/df, /usr/bin/du, /usr/bin/netstat, /usr/bin/curl

             # You can see the full path by command with the which command.

The process of granting authorization is as follows.

Confirm the authorization request from the development team.

• The server accessed, reason, and duration of access must be included.
• There must be approval by the development team lead and DevOps team lead.

The legitimacy of the requested authorization is verified.

If an authorization request comes from the development team, creating accounts for those people is prioritized.

Access control solutions make it easier to separate authorization, but Linux OS features allow for per-user authorization.

Proper authorization to separate operators and developers is possible by referring to the "Cloud Vulnerability Inspection Guide" published by KISA in 2020 and completing security settings afterwards.