Logo Passei Direto
Buscar
Material
páginas com resultados encontrados.
páginas com resultados encontrados.

Prévia do material em texto

Security Engineer Learning Plan (Partner)
AWS Security Fundamentals
Edge locations are physical data centers located in key cities, that are different from Availability Zones. As access to certain data increases with time, this data is copied to an edge location near your customer base for better performance and latency. Threats can then be taken care of at these edge locations, away from your web applications, AWS resources, and the original data.
Getting Started with AWS Security Hub
Security Hub is a cloud security posture management service that performs automated, continuous security best practice checks against your Amazon Web Services (AWS) resources. With Security Hub, you can understand your overall security posture through a consolidated security score across all of your AWS accounts and Regions. You can automatically assess the security of the resources in your AWS accounts through the AWS Foundational Security Best Practices standard and other compliance frameworks.
Security Hub has out-of-the-box integrations with the following:
 Ticketing
 Chat
 Security information and event management (SIEM)
 Security orchestration, automation, and response (SOAR)
 Threat investigation
 Governance, risk, and compliance (GRC)
 Incident management tolos
Automatically Detect and Mitigate Account Compromise Issues
N/A
Securing and Protecting Your Data in Amazon Simple Storage Service (Amazon S3)
Block Public Access overrides other S3 access permissions to easily enforce a no-public-access policy. Using S3 Block Public Access, account administrators and bucket owners can easily set up centralized controls to limit public access to their Amazon S3 resources that are enforced regardless of how the resources are created. This feature is enabled by default.
Access Points simplify managing data access at scale for applications that use shared data sets on Amazon S3. Access points are named network endpoints that are attached to buckets and are used to perform Amazon S3 object operations, such as GetObject and PutObject. Each access point has distinct permissions and network controls that S3 applies for any request that is made through that access point.
With Query String Authentication (presigned URLs), you can grant time-limited access to objects with temporary URLs. You can use a presigned URL to share objects or allow your customers/users to upload objects to buckets without AWS security credentials or permissions.
With Query String Authentication (presigned URLs), you can grant time-limited access to objects with temporary URLs. You can use a presigned URL to share objects or allow your customers/users to upload objects to buckets without AWS security credentials or permissions. 
 AuthenticatedUsers – This group allows all AWS accounts to access the resource. This means any authenticated AWS user, from any AWS account in the world, can access your resource so long as the request is signed (authenticated). 
 AllUsers – This group allows anyone in the world access to the resource. The requests can be signed (authenticated) or unsigned (anonymous).
Access policies dictate who has access to which resources. There are two types of access policies: resource based and identity based. Resource-based policies attach to resources, such as buckets and objects. For example, bucket policies and access control lists (ACLs) are resource-based policies because you attach them directly to resources such as buckets and objects.
Identity policies or IAM policies are access policies attached to users in your account. You might choose to use one type of access policy or a combination of both to manage permissions for your Amazon S3 resources.
Limits on policy size
 User policy size cannot exceed 2,048 characters.
 Role policy size cannot exceed 10,240 characters.
 Group policy size cannot exceed 5,120 characters.
Access points provide simplified control for shared datasets in the same bucket. Each access point has its own access permissions. You add access points as your application set grows. Each application or group can have its own access points. 
Access Points help manage large sets of data without needing to use a long, complex bucket policies. As a bucket policy grows in complexity, managing the policy becomes very time consuming. Access Points also restrict S3 storage access to stay within the virtual private cloud (VPC) thus ensuring your data never leaves the Amazon network. You can also create a service control policy (SCP) and require that all access points be restricted to a VPC. An SCP is a type of policy used to manage permission with AWS Organizations. As a result, a firewall is created around your data within your private networks.
A VPC endpoint is a logical entity within a VPC that allows connectivity to AWS services, such as Amazon S3. The VPC endpoint routes requests across the Amazon network to S3 and then routes responses back to the VPC. Because the traffic stays on the Amazon network, the endpoint allows you to privately connect to supported AWS services without requiring an internet gateway, NAT device, VPN connection, or AWS Direct Connect connection. Traffic between your VPC and the AWS service does not leave the Amazon network.
Endpoints are virtual devices that scale horizontally, are highly available, and redundant. They allow communication between your VPC and AWS services without creating availability risks or bandwidth constraints on your network traffic. VPC endpoints use AWS PrivateLink, a technology that you can implement to privately access services by using private IP addresses.
Gateway endpoints support both Amazon S3 and Amazon DynamoDB. Gateway endpoints are specified in your route table and use the route prefix to direct traffic destined for S3 or DynamoDB to the gateway endpoint. 
Using a gateway endpoint provides a way to access S3 buckets without your data traversing the internet. Requests stay within the AWS network. This keeps private subnets secure because you do not have to add an internet gateway or NAT instance to access S3 data. A private subnet does not have a route to the internet.
An interface endpoint is an elastic network interface (network interface) with a private IP address from the IP address range of your subnet. It serves as an entry point for traffic destined to supported AWS services or to a VPC endpoint service. 
Interface endpoints can easily extend your on-premises networks to connect to your VPC and S3. This reduces the need to operate fleets of proxy servers in your VPC that allow on-premises applications to send data to the private IP of the proxy servers that forward the requests to S3. With interface endpoints, those on-premises applications can send data to the private IP of an interface endpoint. Doing this lessens the added complexity and point-of-failure of the proxy server fleets.
Gateway endpoints work by connecting the specific VPC with the resource (Amazon S3 or DynamoDB) to which it connects. You then add a route in the route table to include the Destination as the service prefix id and the Target as the endpoint ID. After the route is added, any request for Amazon S3 is routed to the endpoint that connects to S3. If the subnet is associated with the modified route table, the subnet is automatically granted access to the endpoint. The default policy automatically grants access to authenticated principals while any security group in use must add a specific rule that allows outbound traffic to the endpoint.
Security and Observability for Serverless Applications
You have three options for authorizing access to your APIs through API Gateway: AWS Identity and Access Management (IAM), Amazon Cognito, and Lambda authorizers. Choose the model that makes the most sense for your existing authentication model and each workload. To learn more, expand each of the following three categories.
IAM is best for clients that are within your AWS environment or can otherwise retrieve IAM temporary credentials to accessyour environment.
Amazon Cognito gives you a managed service that can support sign-in/sign-up capabilities or act as an identity provider (IdP) in a federated identity scenario.
An API Gateway Lambda authorizer invokes a Lambda function to authenticate/validate a user against your existing IdP. This type of authorizer is useful for centralized authentication.
Getting Started with Amazon GuardDuty
N/A
Deep Dive with Security: AWS Identity and Access Management (IAM)
Temporary security credentials can be configured to last from a few minutes to several hours. After the credentials expire, AWS no longer recognizes them or allows any kind of access from API requests made with them.
Temporary security credentials are not stored with the user but are generated dynamically and provided to the user when requested. When (or even before) the temporary security credentials expire, the user can request new credentials as long as the user requesting them still has permissions to do so.
By default, AWS STS is available as a global service, and all AWS STS API requests go to a single endpoint at https://sts.amazonaws.com. When a user or application requires temporary security credentials to access AWS resources, they make the AssumeRole API request. These temporary credentials consist of an access key ID, a secret access key, and a security token. Each time a role is assumed and a set of temporary security credentials is generated, an IAM role session is created.
It is important to note that permission sets are used for only AWS accounts. Permission sets are not used to manage access to cloud applications. Permission sets ultimately get created as IAM roles in a given AWS account, and trust policies allow users to assume the role through AWS SSO.
AWS Security Best Practices: Monitoring and Alerting
With the Amazon CloudWatch Logs service, you can collect and store logs from your resources, applications, and services in near real time. There are three main categories of logs:
 Vended logs: These are natively published by AWS services on your behalf. Currently, Amazon VPC Flow Logs and Amazon Route 53 logs are the two supported types.
 Logs published by AWS services: Currently, more than 30 AWS services publish logs to CloudWatch. They include Amazon API Gateway, AWS Lambda, CloudTrail, and many others.
 Custom logs: These are logs from your own application and on-premises resources.
image1.png
image2.png
image3.jpeg
image4.png
image5.png

Mais conteúdos dessa disciplina