Nilesh Kumar

AWS IAM (Identity and Access Management) in one of the most complex and misunderstood concepts. It's easy to make mistakes while defining proper permissions for resources in the account or cross account. Here are a few basic terminologies from IAM: IAM users: Used for Human users, such as long term security credentials IAM roles: Used for applications, automated services, they are short term security credentials. For example, a Lambda function wants to access EC2 instance. IAM principal: An identity defines within an AWS account Policies: Policies are permissions- they can be attached to Users, Groups or Roles. AWS authorizes every API call against the IAM policies that apply. Breaking down IAM Policy (JSON files): 'Effect' clause: Describes if an action is allowed or not by setting 'Allow' or 'Deny' 'Action' clause: What all actions on a particular resource can be performed. A wild card (*) indicates all actions, which is very insecur...

Nice documentation on how to secure AWS SageMaker: https://docs.aws.amazon.com/sagemaker/latest/dg/security.html

AWS Landing zone: A framework for defining and creating foundations for accounts by automating, baking security baseline, controls, governance, organized, auditable, scalable and self serviceable. A set of best practices ingested in an AWS account before migration. Reliable infrastructure. The tenet of LZ are: - Automation driven versioned infrastructure, such as CI/ CD, Cloudformation templates - Multi-account AWS environment based on AWS best practices, limiting blast radius - Adaptable foundation with guardrails, safeguarding in case of any mis happening - Set of architecture patterns, proxy accesses Building/ Designing LZ components: - Accounts: as discussed Multi account strategy - Network:Domains, Direct Connect, Core Services - Security: Centralized Logging, Configuration, Image (AMI) - IAM: Access, Identity, Federation - Cloud Users: Provide users to deploy the accounts, services by using Service Catalog, Automation (avoid manual steps) etc - Now, Migrate, Iterat...

The below are a few security anti patterns for AWS cloud which should be avoided when implementing comprehensive cloud security strategy: Security Anti-patterns Categories: - Account Structure - N/w design - Auditing - S/W delivery AntiPattern (Account Structure): Personally owned AWS account - Make sure the Root account (login, MFA) is not tied to a person's email id. Root email id should be tied to team DL - Root MFA must be tied with some sort of official hardware device - Contact info etc must be of office address - No one logs into the account root. Use IAM only. Anti-pattern (Account Structure): AWS account overcrowding - Not all and every services/ teams should be placed under one single account. It becomes very hard to manage policy wise and governance wise - If admin creds for the account is compromise, the blast radius will be more, all the services get compromised - If some of the services are in scope for compliance, and since they are not separated, i...

Interesting read on how overlooked, underestimated accounts with over privileges can be misused. This is not new and have been found in traditional corporate environments but now this applies to Cloud environments also. The blog sums it up nicely: https://www.cyberark.com/threat-research-blog/cloud-shadow-admin-threat-10-permissions-protect/

One of the most popular, yet most misunderstood and misconfigured services of AWS, common to be explouited frequently out in wild. Latest on this, a good read: https://www.upguard.com/breaches/facebook-user-data-leak

A Policy is 'Deny' by default Types of Policies: 1. SCP- SCP or Service control polcies. AWS Organizations use this kind of policies.For example, Guardrails to disable service access on the principals in the account. 2. IAM- Permission Policies and Permission Boundaries- Granular permissions on IAM principles (users and roles) and control maximum permissions they can set. 3. AWS STS- Security Token Service- Reduce general shared permissions further 4. Resource based policies: Cross-account access and to control from the resource 5. Endpoint polices- generally attached with VPCs- Control access to the service with a VPC endpoint. How all these policies work together- within an account: SCP AND [IAM policies OR Resource based policies]- If both policies match- then the matched action will be allowed, otherwise denied. How all these policies work together- across accounts: SCP AND [IAM policies AND Resource based policies]- All the 3 must have the same actions matched- the action...