Overview of AWS identity management: Users

By Ashwin Venugopal -

 








First Time Access Only: Your Root User Credentials

As we all know, while creating an AWS account, a one sign-in account called root user (having total access over all the AWS services and resources available in the account) is accessed via the email address as well as the password used while creating the account. this combination of the email address and password is also termed as Root User Credentials.

Since Root User Credentials offers unrestricted access to all the AWS resources (which also includes your billing information and permission to change the password), it's strongly recommended to not use them on regular basis and/or share them with anyone. Only Service Control Policies (SCPs) in organizations can restrict the permissions that are granted to the root user.

IAM Users

The term referred to as authentication helps you in providing the "identity" of the user of IAM. Hence, you can also create your own users (that corresponds to users within your account) within your account instead of sharing your root user credentials with anyone. Each user can have its own password and access key to access the AWS management console in order to work with the resources in your account.

Note: Some of the users can actually be applications that can be created to generate an access key for an application and doesn't need to represent a real person. 

Federating Existing Users

If users in an organization can be authenticated, then, there is no need to create separate IAM users, instead, you can federate their user identities into AWS which can be useful in following cases:
  • Users already have identities in a corporate directory 
If the corporate directory is compatible with Security Assertion Markup Language 2.0, it can be configured to provide single-sign on access to the AWS Management Console for the users.

However, if it's not compatible, then, an identity broker application can be created to provide the single-sign on  access for the users.

If it's a Microsoft AD, then, AWS Directory Service can be used to establish trust between your corporate directory and AWS account.

  • Users already have internet identities

If a mobile app or web-based app is being created that can provide identities via an Internet Identity Provider like Login with Amazon, Facebook, Google, etc., that app can readily use federation to access AWS.   

















































Comments

Post a Comment

Popular posts from this blog

Deployment (Part 3)

By Ashwin Venugopal -
Image
  To read part 1, please click  here To read part 2, please click  here Microsoft Monitoring Agent (MMA) MMA is used across multiple Microsoft solutions and has undergone a few name changes as its features and functionality have evolved. If it is being considered to be used, then following areas should be covered during a Microsoft Sentinel deployment project: Consider the timelines and the strategy for a migration to AMA (Azure Monitor Agent) before the MMA end-of-life.  Consider the central deployment and management methodology for MMA. Determine which endpoints are in scope for deployment as these affect the log ingestion volume significantly.  Azure Monitor Agent (AMA) Organizations with MMA as the main Microsoft Sentinel agent should start planning the migration to AMA as soon as possible to avoid a rushed migration. One of the main advantages of AMA is the ability to control the log collection policy centrally and apply different policies against different...
Read more

Deployment (Part 1)

By Ashwin Venugopal -
Image
  To read part 2, please click  here To read part 3, please click  here Azure Resources Microsoft Sentinel needs following resources to be created: Subscription (if a dedicated subscription(s) will be used) Resource group(s) Log Analytics workspace(s) Automation rules/playbook Alert rules Workbooks Microsoft Sentinel offers hundreds of alert rules, workbooks, and automation playbook templates along with hunting scripts. The templates can be used to activate/deploy schedule alerts, create customized dashboards, create automation playbooks and perform threat-hunting activities. Generally, once deployed, the resources created have to be adjusted to match the existing environment, configure local credentials, etc. Methods of deployment: Manual- Administrator can manually configures the Microsoft Sentinel resources with the help of Azure portal. Any manual process has the inherent risks of human operator error, lack of compliance with potential change control procedures, and u...
Read more

Project Resourcing (Part 2)

By Ashwin Venugopal -
Image
  To read part 1, please click  here Engineering - SIEM The SIEM engineers configures Microsoft Sentinel, including Log Analytics, Logic Apps, workbooks, and playbooks. They are also responsible for the following high-level tasks: Initial configuration of Azure tenant, including provisioning required resources, assigning access roles, and configuring workspace parameters like log retention, resource tagging, and blueprints.  Deployment and configuration of syslog/CEF log collection agents in appropriate locations to collect logs from on-premises devices. Generally, it will be joint effort of both system engineer and SIEM engineer, involving configuration and potential troubleshooting.  Working with system owners to enable log forwarding and configuring any required parsing of log data in Log Analytics.  Working with security operations to create and deploy KQL analytic rules to offer detections for SOC/Computer Security Incident Response Team (CSRIT) use. Tuning...
Read more