One Article Review
| Source |  AlienVault Lab Blog |
|---|---|
| Identifiant | 8297736 |
| Date de publication | 2023-01-04 11:00:00 (vue: 2023-01-04 11:05:46) |
| Titre | Three easy steps to dramatically improve your AWS security posture: Step 1, set up IAM properly |
| Texte | Have you ever heard the saying that the greatest benefit of the cloud is that limitless resources can be spun-up with just a few clicks of the mouse? If so, you would be best served by forgetting that saying altogether. Just because cloud resources can be spun-up with a few clicks of the mouse does not mean that they should be. Rather, prior to launching anything in the cloud, careful consideration and planning are a necessity. Otherwise, your company or governmental entity might end up in the news for a security blunder that was easily avoidable. This blog series will focus on three Amazon Web Services (AWS) security steps that any entity can employ to immediately and dramatically improve their cybersecurity preparedness. Specifically, we will discuss 1) setting up Identity and Access Management (IAM) properly, 2) avoiding direct Internet access to AWS resources, and 3) encryption for data in transit or at rest. These steps can be followed for entities that are either new to AWS or existing customers. Read on to find out if your organization is already following this easy guidance. Step 1: Use IAM the correct way According to AWS, IAM enables account administrators to “specify who or what can access services and resources in AWS, centrally manage fine-grained permissions, and analyze access to refine permissions across AWS.” AWS IAM | Identity and Access Management | Amazon Web Services. When entities first create an AWS account, the only user that exists is the root user. This user has the proverbial “keys to the kingdom” and can literally launch cloud environments that would rival Fortune 500 companies in a short amount of time. In turn, bills commensurate with a Fortune 500 can quickly be accrued, too. Accordingly, as we will discuss below, protecting the root account is a crucial first step. Protect the root account In addition to creating a sufficiently complex password, multifactor authentication (MFA) must be enabled. MFA is achieved by using a third-party authentication mechanism. Since usernames and passwords are stolen with alarming frequency, incorporating login credentials with MFA makes it much more difficult to compromise an account. This is because the malicious user would need to know a user’s login name, password, and possess the user’s third-party authentication mechanism. As long as the latter is securely protected, account compromise is nearly impossible (Note: sessions authenticated with MFA can still be compromised via cross-site scripting (XSS) attacks. As we will learn later, AWS offers a defense against XSS). AWS supports the following MFA mechanisms: Virtual MFA devices (e.g., Google Authenticator, Twilio Authy, etc.); FIDO security key (i.e., a USB device); and Hardware MFA device (i.e., a physical device that generates random numbers). IAM - Multi-Factor Authentication (amazon.com). Conveniently, Virtual MFA can literally be setup in minutes and has no cost associated with it. Additionally, if the AWS root account was created with programmatic access keys, they should be deleted immediately. Even with MFA in place, if these keys fall into the wrong hands, they can be used to launch everything and anything. These keys are akin to “God mode.” Something as simple as accidentally posting the keys on a repo like GitHub is all an attacker would need to take over an account. Hence, it is necessary to delete them and follow the principle of least privilege by divvying up permissions to IAM users, groups, and roles instead. Let’s discuss how to securely create each of these IAM principals now. Create IAM users If all AWS users shared the same login credentials, accountab |
| Notes | ★★★ |
| Envoyé | Oui |
| Condensat | “god “keys “specify account let’s 500 ability about access accidentally according accordingly account accountability accounts accrued achieved across actions active addition additionally addressed administrators affords against akin alarming align all already also altogether amazon amount analyze another answer any anything api application are aspects associate associated associating assume assuming attacker attacks authenticated authentication authenticator author’s authorized authy avoid avoidable avoided avoiding aws basics because below benefit best bills bitcoin blast blog blunder bound bucket business can cannot careful caused centrally change changes cli click clicks cloud com commensurate companies company complex compromise compromised consideration console constraints control convenient conveniently corporate correct cost create created creating creation credentials cross crucial culprit customers customization cybersecurity damage data defense delete deleted department determine device devices difficult direct directory discuss disgruntled divvying does done dramatically duplicate duties each easily easy ec2 effect efficient either employ employee employees enable enabled enables encryption end entities entity environments especially etc even ever every everything exact example existing exists facebook factor fall feasible federated fido find fine first focus folder follow followed following forgetting fortune frequency frequently functionality functions furthermore generates gets github google governmental grained granular greatest group groups guidance hands hardcoding hardware has have heard heavy hence here: how however hundreds iam identity immediate immediately implemented implications important impossible improve incorporating individual instance instances instead internet job just key keys kingdom” know lambda later latter launch launching learn least lets level lifting like likewise limiting limitless literally login long lot luckily make makes malicious manage management manually marketing may mean mechanism mechanisms: merely mfa might mining minutes mode more moreover most mouse move much multi multifactor must name nearly necessary necessity need needs new news next not note: now numbers offers only opinion organization other otherwise out over party password passwords people perform permissions physical place placed planning point policies policy possess possible posting posture: predetermined preparedness principals principle prior privilege problem process programmatic properly protect protected protecting proverbial provider providers provides provision questions quickly radius random rather read reducing refine regarding relatively repo require required resource resources rest rival role roles root same saying scripting securely securing security separate series served services sessions set setting setup shared short should simple since site something specific specifically specify spun step steps stolen sufficiently supports take ten terminate thankfully them therefore these third thousands three thus time too tools transit turn twilio unique update usb use used user user’s usernames users using virtual way web well what when who will within wondering would wrong xss your |
| Tags | |
| Stories | |
| Move | 
|
L'article ne semble pas avoir été repris aprés sa publication.
L'article ne semble pas avoir été repris sur un précédent.