<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>Forem: Vincent Zanetta</title>
    <description>The latest articles on Forem by Vincent Zanetta (@vincentzan).</description>
    <link>https://forem.com/vincentzan</link>
    <image>
      <url>https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F1019018%2Ff2622300-c8bf-43ef-9180-34ffd99a24aa.jpeg</url>
      <title>Forem: Vincent Zanetta</title>
      <link>https://forem.com/vincentzan</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://forem.com/feed/vincentzan"/>
    <language>en</language>
    <item>
      <title>Learn Security Best Practices with Sls-mentor latest Security Package</title>
      <dc:creator>Vincent Zanetta</dc:creator>
      <pubDate>Fri, 08 Dec 2023 13:48:31 +0000</pubDate>
      <link>https://forem.com/slsbytheodo/new-sls-mentor-security-package-41ji</link>
      <guid>https://forem.com/slsbytheodo/new-sls-mentor-security-package-41ji</guid>
      <description>&lt;p&gt;In the realm of cloud computing, serverless has emerged as a popular paradigm, offering a pay-as-you-go model and the ability to scale applications dynamically. However, with such flexibility comes the potential for security vulnerabilities. To address this need, sls-mentor, an open-source tool, has been developed to audit and improve the security of your AWS Serverless applications.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;New Security Rules for Enhanced Protection&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;We are excited to announce the release of new security rules for sls-mentor to further enhance the security of your serverless applications. These rules cover IAM role policies, SQS queues, and RDS instances.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;IAM Role Policies:&lt;/strong&gt;&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;
&lt;strong&gt;No IAM Role Policy with wildcard Resource:&lt;/strong&gt; Using wildcards in IAM role policies can grant excessive access to resources, making it easier for attackers to exploit. To mitigate this risk, we recommend using specific resources in IAM policies instead of wildcards.&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;&lt;strong&gt;SQS Queues:&lt;/strong&gt;&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;
&lt;strong&gt;Encrypt your SQS queues:&lt;/strong&gt; SQS queues store messages, making them potential targets for unauthorized access. To safeguard your message data, encrypt your SQS queues. SQS supports server-side encryption, ensuring that the data is encrypted on the server before it is stored in the queue.&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;&lt;strong&gt;RDS Instances:&lt;/strong&gt;&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;
&lt;strong&gt;Encrypt your RDS instances:&lt;/strong&gt; RDS databases manage sensitive data, and encrypting them is crucial for protecting this information. sls-mentor checks for unencrypted RDS instances and provides instructions on how to enable encryption.&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;&lt;strong&gt;Using sls-mentor to Enhance Security&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;In addition to the newly introduced security rules, sls-mentor already includes a comprehensive set of security checks that cover various aspects of AWS Serverless applications. These include checks for insecure IAM role permissions, vulnerable Lambda function configurations, and unencrypted CloudWatch logs. By leveraging these existing checks and the newly added ones, developers can thoroughly assess and strengthen the security posture of their serverless applications.&lt;/p&gt;

&lt;p&gt;To utilize sls-mentor and benefit from its security enhancement capabilities, follow these simple steps:&lt;/p&gt;

&lt;ol&gt;
&lt;li&gt;
&lt;strong&gt;Run sls-mentor:&lt;/strong&gt; With your AWS credentials configured, run the following command to initiate the security analysis:
&lt;/li&gt;
&lt;/ol&gt;

&lt;div class="highlight js-code-highlight"&gt;
&lt;pre class="highlight shell"&gt;&lt;code&gt;  npx sls-mentor@latest &lt;span class="nt"&gt;--report&lt;/span&gt;
&lt;/code&gt;&lt;/pre&gt;

&lt;/div&gt;



&lt;ol&gt;
&lt;li&gt;
&lt;strong&gt;Review the security report:&lt;/strong&gt; The sls-mentor tool will generate a comprehensive report in your current directory, named &lt;code&gt;.sls-mentor/index.html&lt;/code&gt;. This report provides insights into the security posture of your serverless applications, highlighting areas for improvement and offering actionable recommendations. &lt;strong&gt;Join the Community and Contribute&lt;/strong&gt; We are always striving to enhance sls-mentor’s capabilities and welcome contributions from the community. If you have serverless or serverful knowledge to share, feel free to join our GitHub repository and contribute to our ongoing development efforts. Your contributions will directly impact the security of serverless applications worldwide.&lt;/li&gt;
&lt;/ol&gt;

&lt;p&gt;&lt;strong&gt;Conclusion&lt;/strong&gt; By incorporating sls-mentor into your serverless development workflow, you can proactively identify and address potential security vulnerabilities, ensuring the safety and integrity of your applications in the cloud. Join us in strengthening the security posture of serverless deployments and make your cloud infrastructure more resilient to attacks.&lt;/p&gt;

</description>
      <category>security</category>
      <category>aws</category>
      <category>serverless</category>
    </item>
    <item>
      <title>Configure Authentication to your AWS account in your GitHub actions CI</title>
      <dc:creator>Vincent Zanetta</dc:creator>
      <pubDate>Fri, 24 Nov 2023 09:23:48 +0000</pubDate>
      <link>https://forem.com/slsbytheodo/configure-authentication-to-your-aws-account-in-your-github-actions-ci-13p3</link>
      <guid>https://forem.com/slsbytheodo/configure-authentication-to-your-aws-account-in-your-github-actions-ci-13p3</guid>
      <description>&lt;p&gt;&lt;strong&gt;TL;DR&lt;/strong&gt; Streamline your GitHub Actions CI workflow by addressing the challenge of configuring secure authentication to your AWS account. This article provides concise guidance on ensuring seamless integration while maintaining the highest standards of security.&lt;/p&gt;

&lt;p&gt;I recently packaged my awesome, open-source, AWS stack auditing tool &lt;a href="https://www.sls-mentor.dev/" rel="noopener noreferrer"&gt;SLS-mentor&lt;/a&gt; into a &lt;a href="https://github.com/marketplace/actions/sls-mentor" rel="noopener noreferrer"&gt;github action&lt;/a&gt;. On this occasion, I was confronted with the question of reproducibly configuring AWS authentication on a remote CI/CD job. In this article, I will explain to you how to proceed.&lt;/p&gt;

&lt;p&gt;We are going to configure authentication to an AWS account in a GitHub Actions CI workflow using OIDC-standard short-term credentials authentication. This is particularly useful when you want to delegate the deployment of your AWS infrastructure as code to Github Actions. Compared to long lived credentials like AWS IAM user access keys, utilizing short-lived IAM credentials like OIDC offers a more secure alternative by reducing the exposure window and enhancing the overall resilience of the authentication process.&lt;/p&gt;

&lt;p&gt;I will start by giving a short principle description of the authentication protocol. I you are just looking for a practical tutorial, you can directly jump to the next section.&lt;/p&gt;

&lt;h2&gt;
  
  
  Dive into GH OIDC protocol
&lt;/h2&gt;

&lt;p&gt;Now maybe you are wondering about what is happening under the hood when you set up this authentication method.&lt;/p&gt;

&lt;p&gt;The OIDC protocol that we configure is a standard based upon the OAuth 2.0 protocol that provides secure identity certification.&lt;/p&gt;

&lt;p&gt;&lt;a href="https://media.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fraw.githubusercontent.com%2Fvincentzan%2Farticles%2Fmaster%2Fblog-posts%2Faws-authentication-gh-actions%2Fassets%2Fschema.png" class="article-body-image-wrapper"&gt;&lt;img src="https://media.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fraw.githubusercontent.com%2Fvincentzan%2Farticles%2Fmaster%2Fblog-posts%2Faws-authentication-gh-actions%2Fassets%2Fschema.png" title="principle schema" alt="schema"&gt;&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;You need to create a trust relationship between GH OIDC provider (also called IdP for identity provider) and AWS IAM. Note that for Github actions it is a third party distinct from Github (called Digicert). This is what is done when you clicked “get thumbprint” on the setup. In response, the authorisation server responds with a public key (for the RS256 protocol). With the latter, the cloud provider can check (and only check) the validity of a given JWT token. When you create a trust relationship between IAM and an OIDC identity provider, you are trusting identities authenticated by that IdP (identified by their website url, or DNS) to have access to a certain scope AWS account. Each CI job (i.e. each instance of a Github virtual machine CI/CD runner) requests an OIDC token from GitHub's Identity provider, which responds with a unique, automatically generated JSON web token (JWT). When the job runs, the OIDC token is presented to the cloud provider (in our case, to the STS service, from which we ask short term credentials in order to assume a role as the github runner). To validate the token, the cloud provider first checks it authenticity and second it checks if the OIDC token's subject and other claims are a match for the conditions that were preconfigured on the cloud role's OIDC trust definition. For example, the token will check the audience and the subjects as we have set in the Trust Policy.&lt;/p&gt;

&lt;p&gt;To fully authenticate your GitHub action runner with your AWS account, we are going to follow 3 main steps :&lt;/p&gt;

&lt;ol&gt;
&lt;li&gt;Configure an OIDC trust relationship between AWS IAM and Github Actions&lt;/li&gt;
&lt;li&gt;Create a minimal IAM role for the CI workflow to assume.&lt;/li&gt;
&lt;li&gt;Configure the authentication in your CI workflow.&lt;/li&gt;
&lt;/ol&gt;

&lt;h2&gt;
  
  
  Configure an OIDC trust relationship between AWS IAM and Github Actions
&lt;/h2&gt;

&lt;p&gt;First you want to tell AWS IAM to acknowledge the Github identity provider as a secure Identity Certificating Authority, that is an Identity Provide (IdP).&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;Go to the AWS IAM console and under identity providers click “Add provider” under provider type specify OIDC (last generation, JSON-based while SAML is XML based)&lt;/li&gt;
&lt;li&gt;For provider URL, enter the URL of the GitHub OIDC IdP for this solution: &lt;a href="https://token.actions.githubusercontent.com/" rel="noopener noreferrer"&gt;https://token.actions.githubusercontent.com&lt;/a&gt;
&lt;/li&gt;
&lt;li&gt;Click on “Get thumbprint”&lt;/li&gt;
&lt;li&gt;Audience, enter &lt;a href="http://sts.amazonaws.com/" rel="noopener noreferrer"&gt;sts.amazonaws.com&lt;/a&gt;:&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;&lt;a href="https://media.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fraw.githubusercontent.com%2Fvincentzan%2Farticles%2Fmaster%2Fblog-posts%2Faws-authentication-gh-actions%2Fassets%2Ftuto1.png" class="article-body-image-wrapper"&gt;&lt;img src="https://media.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fraw.githubusercontent.com%2Fvincentzan%2Farticles%2Fmaster%2Fblog-posts%2Faws-authentication-gh-actions%2Fassets%2Ftuto1.png" title="congigure Github identity provider" alt="tuto1"&gt;&lt;/a&gt;&lt;/p&gt;

&lt;h2&gt;
  
  
  Create a minimal IAM role for the CI workflow to assume.
&lt;/h2&gt;

&lt;ul&gt;
&lt;li&gt;Click on the newly created identity provider&lt;/li&gt;
&lt;li&gt;Click on “Assign role”&lt;/li&gt;
&lt;li&gt;Create new role&lt;/li&gt;
&lt;li&gt;In the Audience list, select &lt;a href="http://sts.amazonaws.com/" rel="noopener noreferrer"&gt;sts.amazonaws.com&lt;/a&gt;
&lt;/li&gt;
&lt;li&gt;Fill in the Github organization (note that AWS has inferred that we are configuring GitHub there).&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;On the next page you need to select the minimal role you need your CI/CD to assume in order to The least privilege principle in AWS IAM emphasizes assigning the minimal permissions necessary for a specific task to prevent over-authorization. This practice enhances security by reducing the attack surface and minimizing the potential impact of compromised credentials.&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;Knowing this, select the role you want your CI/CD to be able to assume&lt;/li&gt;
&lt;li&gt;Check the trust policy of the role : it should read as follows :&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;&lt;a href="https://media.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fraw.githubusercontent.com%2Fvincentzan%2Farticles%2Fmaster%2Fblog-posts%2Faws-authentication-gh-actions%2Fassets%2Ftuto2.png" class="article-body-image-wrapper"&gt;&lt;img src="https://media.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fraw.githubusercontent.com%2Fvincentzan%2Farticles%2Fmaster%2Fblog-posts%2Faws-authentication-gh-actions%2Fassets%2Ftuto2.png" title="configure trust policy" alt="tuto2"&gt;&lt;/a&gt;&lt;/p&gt;

&lt;div class="highlight js-code-highlight"&gt;
&lt;pre class="highlight yaml"&gt;&lt;code&gt;

&lt;span class="s1"&gt;'&lt;/span&gt;&lt;span class="s"&gt;Condition'&lt;/span&gt;&lt;span class="err"&gt;:&lt;/span&gt;
  &lt;span class="pi"&gt;{&lt;/span&gt;
    &lt;span class="s1"&gt;'&lt;/span&gt;&lt;span class="s"&gt;StringEquals'&lt;/span&gt;&lt;span class="pi"&gt;:&lt;/span&gt;
      &lt;span class="pi"&gt;{&lt;/span&gt;
        &lt;span class="s1"&gt;'&lt;/span&gt;&lt;span class="s"&gt;token.actions.githubusercontent.com:aud'&lt;/span&gt;&lt;span class="pi"&gt;:&lt;/span&gt; &lt;span class="s1"&gt;'&lt;/span&gt;&lt;span class="s"&gt;sts.amazonaws.com'&lt;/span&gt;&lt;span class="pi"&gt;,&lt;/span&gt;
        &lt;span class="s1"&gt;'&lt;/span&gt;&lt;span class="s"&gt;token.actions.githubusercontent.com:sub'&lt;/span&gt;&lt;span class="pi"&gt;:&lt;/span&gt; &lt;span class="s1"&gt;'&lt;/span&gt;&lt;span class="s"&gt;repo:octo-org/octo-repo:ref:refs/heads/octo-branch'&lt;/span&gt;&lt;span class="pi"&gt;,&lt;/span&gt;
      &lt;span class="pi"&gt;},&lt;/span&gt;
  &lt;span class="pi"&gt;}&lt;/span&gt;


&lt;/code&gt;&lt;/pre&gt;

&lt;/div&gt;
&lt;h2&gt;
  
  
  Configure the authentication in your CI workflow.
&lt;/h2&gt;

&lt;p&gt;Now going back to the Github actions jobs in your CI/CD workflow. How do make it authenticate using the process we have just set up?&lt;/p&gt;

&lt;p&gt;To do so, we are going to leverage the power of the Github actions marketplace. Indeed, AWS provides us with the code to authenticate the runner machine with the AWS client wrapped in a Github action simply available from the Github actions marketplace. You just need to add this action as a step to your workflow. Don’t forget to carefully replace with the role with the arn of the role you just created.&lt;/p&gt;
&lt;div class="highlight js-code-highlight"&gt;
&lt;pre class="highlight yaml"&gt;&lt;code&gt;

&lt;span class="pi"&gt;-&lt;/span&gt; &lt;span class="na"&gt;name&lt;/span&gt;&lt;span class="pi"&gt;:&lt;/span&gt; &lt;span class="s"&gt;Configure AWS Credentials&lt;/span&gt;
    &lt;span class="s"&gt;uses&lt;/span&gt;&lt;span class="err"&gt;:&lt;/span&gt; &lt;span class="s"&gt;aws-actions/configure-aws-credentials@v3&lt;/span&gt;
    &lt;span class="s"&gt;with&lt;/span&gt;&lt;span class="err"&gt;:&lt;/span&gt;
        &lt;span class="na"&gt;role-to-assume&lt;/span&gt;&lt;span class="pi"&gt;:&lt;/span&gt; &lt;span class="s"&gt;arn:aws:iam::111122223333:role/GitHubAction-AssumeRoleWithAction&lt;/span&gt; &lt;span class="c1"&gt;#change to reflect your IAM role’s ARN&lt;/span&gt;
        &lt;span class="na"&gt;role-session-name&lt;/span&gt;&lt;span class="pi"&gt;:&lt;/span&gt; &lt;span class="s"&gt;GitHub_to_AWS_via_FederatedOIDC&lt;/span&gt;


&lt;/code&gt;&lt;/pre&gt;

&lt;/div&gt;

&lt;p&gt;Finally, add the following permissions to your job&lt;/p&gt;

&lt;div class="highlight js-code-highlight"&gt;
&lt;pre class="highlight yaml"&gt;&lt;code&gt;

&lt;span class="na"&gt;permissions&lt;/span&gt;&lt;span class="pi"&gt;:&lt;/span&gt;
  &lt;span class="na"&gt;id-token&lt;/span&gt;&lt;span class="pi"&gt;:&lt;/span&gt; &lt;span class="s"&gt;write&lt;/span&gt; &lt;span class="c1"&gt;# This is required for requesting the JWT&lt;/span&gt;
  &lt;span class="na"&gt;contents&lt;/span&gt;&lt;span class="pi"&gt;:&lt;/span&gt; &lt;span class="s"&gt;read&lt;/span&gt; &lt;span class="c1"&gt;# This is required for actions/checkout&lt;/span&gt;


&lt;/code&gt;&lt;/pre&gt;

&lt;/div&gt;

&lt;p&gt;That’s it, you are all set!&lt;/p&gt;

&lt;h2&gt;
  
  
  Sources:
&lt;/h2&gt;

&lt;p&gt;&lt;a href="https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services" rel="noopener noreferrer"&gt;https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;&lt;a href="https://github.com/aws-actions/configure-aws-credentials#configure-aws-credentials-for-github-actions" rel="noopener noreferrer"&gt;https://github.com/aws-actions/configure-aws-credentials#configure-aws-credentials-for-github-actions&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;&lt;a href="https://datatracker.ietf.org/doc/html/rfc6749.html#section-1.4" rel="noopener noreferrer"&gt;https://datatracker.ietf.org/doc/html/rfc6749.html#section-1.4&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;&lt;a href="https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc_verify-thumbprint.html" rel="noopener noreferrer"&gt;https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc_verify-thumbprint.html&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;&lt;a href="https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html" rel="noopener noreferrer"&gt;https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;&lt;a href="https://auth0.com/docs/get-started/applications/signing-algorithms" rel="noopener noreferrer"&gt;https://auth0.com/docs/get-started/applications/signing-algorithms&lt;/a&gt;&lt;/p&gt;

</description>
    </item>
    <item>
      <title>Enable HTTPS-only on your S3 buckets</title>
      <dc:creator>Vincent Zanetta</dc:creator>
      <pubDate>Thu, 23 Mar 2023 12:34:02 +0000</pubDate>
      <link>https://forem.com/slsbytheodo/enable-https-only-on-your-s3-buckets-36eg</link>
      <guid>https://forem.com/slsbytheodo/enable-https-only-on-your-s3-buckets-36eg</guid>
      <description>&lt;p&gt;&lt;em&gt;Easily configure your S3 buckets to allow only encrypted requests. Quickly check if your stack complies with sls-mentor! 📈&lt;/em&gt;&lt;/p&gt;

&lt;p&gt;Serverless architectures have a reputation of safety because part of the cybersecurity risk is managed by the cloud provider. This does not mean you should not do anything on your side about it. Hopefully, it is often simple to improve security on a serverless app: setting up the right configurations for your AWS resources can help you increase the overall security of your app at low cost. More specifically, if you’re building a serverless app with AWS there’s a good chance you’re using S3 storage. As a data store, it is crucial to avoid security vulnerabilities with this resource.&lt;/p&gt;

&lt;h2&gt;
  
  
  Why is it important to secure your S3 buckets?
&lt;/h2&gt;

&lt;p&gt;We often hear about encryption of data at rest i.e. in the bucket, which is a first step for securing your data. But the data could also be intercepted while in transit i.e. when it's being transferred over an HTTP request, creating... a data breach! 💀&lt;/p&gt;

&lt;p&gt;&lt;a href="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fraw.githubusercontent.com%2Fvincentzan%2Farticles%2Fmaster%2Fblog-posts%2Fhttps-s3-sls-mentor%2Fassets%2Fmeme-data-breach.gif" class="article-body-image-wrapper"&gt;&lt;img src="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fraw.githubusercontent.com%2Fvincentzan%2Farticles%2Fmaster%2Fblog-posts%2Fhttps-s3-sls-mentor%2Fassets%2Fmeme-data-breach.gif" title="meme data breach" alt="meme data breach" width="695" height="390"&gt;&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;A solution consists in encrypting the data in the request. This can be done simply by using the widespread HTTPS protocol 🤝 for posting requests to the database. Essentially, it uses transport layer encryption, an asymmetric cryptographic protocol which means the encryption key (call it &lt;code&gt;x&lt;/code&gt;) is public but the decryption key is private. To centralize and authenticate the public keys, a third party called a certificate authority issues a proof that public key &lt;code&gt;x&lt;/code&gt; is indeed associated with domain name &lt;code&gt;d&lt;/code&gt; for a given period of time. The certificate authority issues a document called an HTTPS certificate. There are different levels of certification depending on how thoroughly the analysis of the issuing party is conducted. When making a request over HTTPS, it is thus possible to encrypt the data such that a certain domain name &lt;em&gt;only&lt;/em&gt; can decrypt it. With this system, the request data is end-to-end encrypted. This is what we want to enforce for our S3 queries. In contrast, plain old HTTP requests are not encrypted thus are vulnerable to &lt;a href="https://csrc.nist.gov/glossary/term/man_in_the_middle_attack" rel="noopener noreferrer"&gt;man-in-the-middle&lt;/a&gt; and eavesdropping attacks.&lt;/p&gt;

&lt;p&gt;&lt;a href="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fraw.githubusercontent.com%2Fvincentzan%2Farticles%2Fmaster%2Fblog-posts%2Fhttps-s3-sls-mentor%2Fassets%2Fpublic-key-cryptography.jpg" class="article-body-image-wrapper"&gt;&lt;img src="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fraw.githubusercontent.com%2Fvincentzan%2Farticles%2Fmaster%2Fblog-posts%2Fhttps-s3-sls-mentor%2Fassets%2Fpublic-key-cryptography.jpg" title="asymmetric cryptography schema" alt="schema schemaPublicPrivateEncryption" width="800" height="319"&gt;&lt;/a&gt; &lt;em&gt;Principle of public-private key encryption. Image from &lt;a href="https://www.twilio.com/blog/what-is-public-key-cryptography" rel="noopener noreferrer"&gt;https://www.twilio.com/blog/what-is-public-key-cryptography&lt;/a&gt;&lt;/em&gt;&lt;/p&gt;

&lt;p&gt;&lt;a href="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fraw.githubusercontent.com%2Fvincentzan%2Farticles%2Fmaster%2Fblog-posts%2Fhttps-s3-sls-mentor%2Fassets%2Fmeme-https.jpg" class="article-body-image-wrapper"&gt;&lt;img src="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fraw.githubusercontent.com%2Fvincentzan%2Farticles%2Fmaster%2Fblog-posts%2Fhttps-s3-sls-mentor%2Fassets%2Fmeme-https.jpg" title="meme https" alt="meme https" width="735" height="500"&gt;&lt;/a&gt;&lt;/p&gt;

&lt;h2&gt;
  
  
  How to fix it?
&lt;/h2&gt;

&lt;p&gt;To enforce a configuration where only HTTPS requests will be allowed on your S3 bucket, you need to change its access policy (also called permission boundaries). The access policy of the bucket is the way AWS allows to set its configuration. It is an object made of a version, a name and a list of statements. Each element of the latter is an object that describes the different rules that apply to your bucket. Each rule is a set of property assignments:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;effect sets if the statement will allow or deny access e.g. &lt;code&gt;Allow&lt;/code&gt;;&lt;/li&gt;
&lt;li&gt;principal is the user or account that the statement applies to e.g. &lt;code&gt;awesome-user&lt;/code&gt;;&lt;/li&gt;
&lt;li&gt;action is the resource actions (e.g. &lt;code&gt;s3:GetObject&lt;/code&gt;) in scope of the statement;&lt;/li&gt;
&lt;li&gt;the resource is the list of AmazonResourceNames (ARNs) of the objects. It is a long string that begins with &lt;code&gt;arn:aws:s3:::\*&lt;/code&gt; e.g. &lt;code&gt;arn:aws:s3:::my-stack-my-chicken-wings-bucket423e3a42f3-432f3j2&lt;/code&gt;;&lt;/li&gt;
&lt;li&gt;the condition is a &lt;a href="https://docs.aws.amazon.com/AmazonS3/latest/userguide/amazon-s3-policy-keys.html" rel="noopener noreferrer"&gt;property&lt;/a&gt; that states when the policy applies: in our case we want to deny access when the &lt;code&gt;aws:SecureTransport&lt;/code&gt; is &lt;code&gt;false&lt;/code&gt;;&lt;/li&gt;
&lt;li&gt;you can tag your statement to group resources which share the same tag e.g. &lt;code&gt;"food-bucket"&lt;/code&gt;.&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;Now that the access policy is no secret to you, I bet you are rushing to you S3 permission tab and if need be, you append a policy statement where ‘Effect’ is set to ‘Deny’ ❌, where “Resource” is set to the AmazonResourceName of your bucket and Condition.Bool.aws:SecureTransport is set to false, just like below.&lt;br&gt;
&lt;/p&gt;

&lt;div class="highlight js-code-highlight"&gt;
&lt;pre class="highlight json"&gt;&lt;code&gt;&lt;span class="p"&gt;{&lt;/span&gt;&lt;span class="w"&gt;
  &lt;/span&gt;&lt;span class="nl"&gt;"Effect"&lt;/span&gt;&lt;span class="p"&gt;:&lt;/span&gt;&lt;span class="w"&gt; &lt;/span&gt;&lt;span class="s2"&gt;"Deny"&lt;/span&gt;&lt;span class="p"&gt;,&lt;/span&gt;&lt;span class="w"&gt;

  &lt;/span&gt;&lt;span class="nl"&gt;"Principal"&lt;/span&gt;&lt;span class="p"&gt;:&lt;/span&gt;&lt;span class="w"&gt; &lt;/span&gt;&lt;span class="s2"&gt;"*"&lt;/span&gt;&lt;span class="p"&gt;,&lt;/span&gt;&lt;span class="w"&gt;
  &lt;/span&gt;&lt;span class="nl"&gt;"Action"&lt;/span&gt;&lt;span class="p"&gt;:&lt;/span&gt;&lt;span class="w"&gt; &lt;/span&gt;&lt;span class="s2"&gt;"s3:*"&lt;/span&gt;&lt;span class="p"&gt;,&lt;/span&gt;&lt;span class="w"&gt;
  &lt;/span&gt;&lt;span class="nl"&gt;"Resource"&lt;/span&gt;&lt;span class="p"&gt;:&lt;/span&gt;&lt;span class="w"&gt; &lt;/span&gt;&lt;span class="p"&gt;[&lt;/span&gt;&lt;span class="s2"&gt;"resourceName1/*"&lt;/span&gt;&lt;span class="p"&gt;,&lt;/span&gt;&lt;span class="w"&gt; &lt;/span&gt;&lt;span class="s2"&gt;"resourceName2"&lt;/span&gt;&lt;span class="p"&gt;],&lt;/span&gt;&lt;span class="w"&gt;
  &lt;/span&gt;&lt;span class="nl"&gt;"Condition"&lt;/span&gt;&lt;span class="p"&gt;:&lt;/span&gt;&lt;span class="w"&gt; &lt;/span&gt;&lt;span class="p"&gt;{&lt;/span&gt;&lt;span class="w"&gt;
    &lt;/span&gt;&lt;span class="nl"&gt;"Bool"&lt;/span&gt;&lt;span class="p"&gt;:&lt;/span&gt;&lt;span class="w"&gt; &lt;/span&gt;&lt;span class="p"&gt;{&lt;/span&gt;&lt;span class="w"&gt;
      &lt;/span&gt;&lt;span class="nl"&gt;"aws:SecureTransport"&lt;/span&gt;&lt;span class="p"&gt;:&lt;/span&gt;&lt;span class="w"&gt; &lt;/span&gt;&lt;span class="s2"&gt;"false"&lt;/span&gt;&lt;span class="w"&gt;
    &lt;/span&gt;&lt;span class="p"&gt;}&lt;/span&gt;&lt;span class="w"&gt;
  &lt;/span&gt;&lt;span class="p"&gt;}&lt;/span&gt;&lt;span class="w"&gt;
&lt;/span&gt;&lt;span class="p"&gt;}&lt;/span&gt;&lt;span class="w"&gt;
&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;

&lt;/div&gt;



&lt;p&gt;Now your S3 data is also encrypted in transit! easy peazy!&lt;/p&gt;

&lt;h2&gt;
  
  
  Run an analysis with Sls-mentor
&lt;/h2&gt;

&lt;p&gt;&lt;a href="https://sls-mentor.dev/" rel="noopener noreferrer"&gt;Sls-mentor&lt;/a&gt; can help you implement good practices on your AWS stack. It is an open source audit tool running directly from the terminal which will audit your resource stack. It will go through a list of good practice criteria and pinpoint you where there is room for improvement. For example, it is also First you should encrypt your S3 bucket on the server side so that the data is not readable if unfortunately data is maliciously retrieved from then. This can be done with simple, free S3-managed configuration (ServerSideEncryption-S3). From January 2023, this is done &lt;a href="https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucket-encryption.html" rel="noopener noreferrer"&gt;by default&lt;/a&gt; on all newly uploaded objects on S3 buckets.&lt;/p&gt;

&lt;p&gt;In addition to enforcing encryption at rest and in transit, carefully setting the permissions statements of an S3 bucket can allow you to block requests from anonymous or undesirable users. Deep dive into the configuration of the permission statements and apply &lt;a href="https://aws.amazon.com/blogs/security/how-to-use-bucket-policies-and-apply-defense-in-depth-to-help-secure-your-amazon-s3-data/" rel="noopener noreferrer"&gt;defense in depth&lt;/a&gt; 🤿.&lt;/p&gt;

&lt;h2&gt;
  
  
  Conclusion
&lt;/h2&gt;

&lt;p&gt;Always set the right configuration for your S3 bucket and make your serverless apps safer!&lt;/p&gt;

</description>
      <category>https</category>
      <category>rest</category>
      <category>s3</category>
      <category>aws</category>
    </item>
  </channel>
</rss>
