Data Security in the AWS Cloud
Users, Roles, and Rights
In the AWS cloud, the simplest hierarchy level is that of accounts containing users who are assigned authorizations within the account, such as the ability to create and start VMs or databases. The IAM configuration area is used to manage users or admins.
AWS recommends setting up accounts with sub-accounts. This allows the AWS customer to impose company-wide policies so that even an admin with full rights for a sub-account cannot violate the organizational rules.
When generating an account, AWS also creates the superuser's credentials for this account. By clicking on the user list, the admin will find this superuser. The user has full access to all functions offered by AWS (the exception would be a sub-account with an organizational policy). If the admin creates a second user here, the user is only granted explicitly assigned rights. When creating a new user, you are first prompted for the user name and details of how this user will log on, via CLI/API and/or the Web Console.
Next, the admin assigns rights by selecting from existing user groups (for example S3 Admins, Networkadmins, etc.), assigning roles (S3 Admin, Networkadmin), or as individual assignments at policy level. If you really want to make your life complicated, you can also define an arbitrary combination of these rights for the new user.
To avoid selecting overly liberal permissions by mistake, a permissions boundary can be defined within which, say, the security administrator responsible for AWS restricts permissions in a policy. If a conflict then arises between this limitation and the assigned rights, the limitation wins.
Rights to Resources
AWS controls access through policies. A policy consists of a set of statements, each granting one or more rights to a resource (with wild cards) to a role or user. Optional conditions are possible. Listing 1 shows a section of a policy in JSON format [1].
Listing 1
JSON Policy Definition
01 { 02 "Version": "2012-10-17", 03 { 04 "Sid": "s3zugriff", 05 "Effect": "Allow", 06 "Action": [ 07 "s3:List*", 08 "s3:Get*" 09 ], 10 "Resource": [ 11 "arn:aws:s3:::confidential-data", 12 "arn:aws:s3:::confidential-data/*" 13 ], 14 "Condition": {"Bool": {"aws:MultiFactorAuthPresent": "true"}} 15 } 16 ] 17 }
The Sid
field contains a name for the permission, but it is optional. Effect
allows or denies access. The Action
field contains a list of the API access instances at issue. In the example, these are all listing and downloading operations in the S3 API. The Resource
field contains a list of targets for the operations, formulated as Amazon Resource Names (ARNs). The example shows a bucket named confidential-data
and its contents. If you do not include the last field Condition
, then the rule would be universal.
The condition in line 14 ensures multi-factor authentication of the user for this rule to apply. Depending on the logic to be mapped, the admin either writes individual policies in this form and combines them or bundles several statements into a single policy.
The Right to Interact
Policies are not only used for user access controls, but also to govern the interaction between AWS entities. A lambda function wanting to send a Simple Notification Service (SNS) [2], for example, needs a role that contains a policy with the corresponding rights in the SNS area.
Policies determine which operations are allowed on which objects. The admin assigns them to users or functions. In regard to the CIA triad, a policy controls who can access the data within the created AWS objects. This does not consider the confidentiality and integrity objectives in relation to the AWS administrators.
« Previous 1 2 3 4 Next »
Buy this article as PDF
(incl. VAT)
Buy Linux Magazine
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters
Support Our Work
Linux Magazine content is made possible with support from readers like you. Please consider contributing when you've found an article to be beneficial.
News
-
Red Hat Migrates RHEL from Xorg to Wayland
If you've been wondering when Xorg will finally be a thing of the past, wonder no more, as Red Hat has made it clear.
-
PipeWire 1.0 Officially Released
PipeWire was created to take the place of the oft-troubled PulseAudio and has finally reached the 1.0 status as a major update with plenty of improvements and the usual bug fixes.
-
Rocky Linux 9.3 Available for Download
The latest version of the RHEL alternative is now available and brings back cloud and container images for ppc64le along with plenty of new features and fixes.
-
Ubuntu Budgie Shifts How to Tackle Wayland
Ubuntu Budgie has yet to make the switch to Wayland but with a change in approaches, they're finally on track to making it happen.
-
TUXEDO's New Ultraportable Linux Workstation Released
The TUXEDO Pulse 14 blends portability with power, thanks to the AMD Ryzen 7 7840HS CPU.
-
AlmaLinux Will No Longer Be "Just Another RHEL Clone"
With the release of AlmaLinux 9.3, the distribution will be built entirely from upstream sources.
-
elementary OS 8 Has a Big Surprise in Store
When elementary OS 8 finally arrives, it will not only be based on Ubuntu 24.04 but it will also default to Wayland for better performance and security.
-
OpenELA Releases Enterprise Linux Source Code
With Red Hat restricting the source for RHEL, it was only a matter of time before those who depended on that source struck out on their own.
-
StripedFly Malware Hiding in Plain Sight as a Cryptocurrency Miner
A rather deceptive piece of malware has infected 1 million Windows and Linux hosts since 2017.
-
Experimental Wayland Support Planned for Linux Mint 21.3
As with most Linux distributions, the migration to Wayland is in full force. While some distributions have already made the move, Linux Mint has been a bit slower to do so.