Allowed AMIs in Amazon EC2 (Part 2)

By Ashwin Venugopal -

 






Allowed AMIs operations

The Allowed AMIs feature offers three operational modes for overseeing the image criteria: enabled, disabled, and audit mode. These modes allow you to activate or deactivate the image criteria, or examine them when necessary.

Enabled

When Allowed AMIs is enabled:

  • The ImageCriteria are applied.

  • Only allowed AMIs are discoverable in the EC2 console and by APIs that use images

  • Instances can only be launched using allowed AMIs.

Disabled

When Allowed AMIs is disabled:

  • The ImageCriteria are not applied.

  • No restrictions are placed on AMI discoverability or usage.

Audit mode

In audit mode:

  • The ImageCriteria are applied, but no restrictions are placed on AMI discoverability or usage.

  • In the EC2 console, for each AMI, the Allowed image field displays either Yes or No to indicate whether the AMI will be discoverable and available to users in the account when Allowed AMIs is enabled.

  • In the command line, the response for the describe-image operation includes "ImageAllowed": true or "ImageAllowed": false to indicate whether the AMI will be discoverable and available to users in the account when Allowed AMIs is enabled.

  • In the EC2 console, the AMI Catalog displays Not allowed next to AMIs that won't be discoverable or available to users in the account when Allowed AMIs is enabled.

Best practices for implementing Allowed AMIs

  • Enable audit mode- Start by activating Allowed AMIs in audit mode. This setting lets you observe which AMIs would be impacted by your criteria without enforcing any access restrictions, allowing for a risk-free assessment timeframe.

  • Set Allowed AMIs criteria- Carefully establish which AMI providers align with your organization's security policies, compliance requirements, and operational needs.

  • Check for impact on expected business processes- You can utilize the console or the CLI to locate any instances that were initiated with AMIs that don't comply with the defined standards. This insight can help you decide whether to modify your launch configurations to employ compliant AMIs or to change your criteria to accept these AMIs.

  • Enable Allowed AMIs- After verifying that the criteria will not negatively impact anticipated business processes, proceed to enable Allowed AMIs.

  • Monitor instance launches- Keep an eye on instance launches from AMIs throughout your applications and the AWS managed services in use, including Amazon EMR, Amazon ECR, Amazon EKS, and AWS Elastic Beanstalk. Look for any unanticipated problems and make adjustments to the Allowed AMIs criteria as needed.

  • Pilot new AMIs- To test third-party AMIs that do not comply with your current Allowed AMIs settings, AWS recommends the following approaches:

    • Use a separate AWS account: Create an account with no access to your business-critical resources. Ensure that the Allowed AMIs setting is not enabled in this account, or that the AMIs you want to test are explicitly allowed, so that you can test them.

    • Test in another AWS Region: Use a Region where the third-party AMIs are available, but where you have not yet enabled the Allowed AMIs settings.

These approaches help ensure your business-critical resources remain secure while you test new AMIs.

Conclusion

Other aspects of Allowed AMIs operations are discussed in detail.






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

Deployment (Part 2)

By Ashwin Venugopal -
Image
  To read part 1, please click  here To read part 3, please click  here Microsoft Sentinel Content Hub Content in Microsoft Sentinel includes any of the following types: Data connectors offer log ingestion from different sources into Microsoft Sentinel. Parsers give log formatting/transformation into ASIM formats, supporting usage across various Microsoft Sentinel content types and scenarios. Workbooks provide monitoring, visualization, and interactively with data in Microsoft Sentinel, highlighting meaningful insights for users.  Analytics rules give alerts that point to relevant SOC actions via incidents.  Hunting Queries are used by SOC teams to proactively hunt for threats in Microsoft Sentinel. Notebooks help SOC teams in using advanced hunting features in Jupyter and Azure Notebooks. Watchlists support the ingestion of specific data for enhanced threat detection and reduced alert fatigue.  Playbooks and Azure Logic Apps Custom Connectors provide featu...
Read more