Enterprise Application Security

  • Keep all servers in a VPC.
  • In a typical deployment without edge servers, ALB (Application Load Balancer) is the first entry point for the incoming requests. This needs to be configured with the necessary WAF(Web Application Firewall) rules. In AWS there are third-party WAF rule set providers such as Fortinet, which is very easy to setup.
  • Make sure none of ec2 instances are having external IPs except the bastion host (this is the gateway /proxy to connect to ec2 instances running the back end services), which shall have only ssh enabled via public key whitelisting specified in .ssh/authorized_keys in the home directory.
  • Don’t use .pem files to connect to the server instances, use above method instead.
  • Use VPC peering for the third party database services such as MongoDb Atlas, Scalegrid.
  • Configure MFA for all cloud management consoles (AWS, GCP, MongoDB Atlas, Scalegrid or Confluent Cloud) as well as version control systems github/gitlab.
  • All databases should be connected using strong authentication mechanisms provided by the database systems. If Postgres is being used, configure it with IP whitelisting for access control. Postgres is by default open to the world.
  • Patch the servers regularly with the security updates of OS and third party packages installed in them.
  • Do not include any secrets in the AMIs or any backup snapshots.
  • Implement rate limiting controls at WAF or at individual service level.
  • Hide HTTP response headers, which expose information about the OS and back end service framework.
  • Change SSH port from default.
  • Setup git hooks to scan for secrets in the code repository and also make secrets scanning part of CI/CD pipeline.
  • Periodically scan the third party packages for the vulnerabilities. For example in nodejs based services, run `npm audit`.
  • Implement RBAC(Role based access control) in the applications, so that there are no un authorized actions are performed by the users. This needs to be a double layered, which means it has to be implemented in both UI as well as back end services.
  • Implement strong passwords or Google or any other OAuth providers for login/signup.
  • Implement blocking of account/IP of the requestor if 5 times consecutively wrong credentials are provided in a short span of time lets say 10 minutes. This could potentially be a brute-force attack to get one of the user’s credentials.
  • Identify and mask sensitive database fields while restoring data into non production environments or developer’s machines.
  • Serve all the reports or any other sensitive data files (may be stored in s3) under authorization check. In short do not have public access to the s3 buckets which hold this kind of data. Instead serve them via temporary pre-signed short lived urls or using nginx proxy pass.
  • Hide the sensitive/unauthorized data at the API response level based on the user’s role.

--

--

--

An entrepreneur with a decade of experience in building MEAN stack SaaS platforms.

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

1. Python basics for beginners

5 Python Libraries You Use a Lot

Must-have Intellij plugins for any programming languages

Internship Experience with LGM

Amara.finance x Im Community AMA Recap

Design your landing pages automatically in just a few seconds using artificial intelligence

Google Cloud Functions Tutorial : Using Environment variables

Jerry: 🚀🚀🚀🚀🚀🚀🚀🚀🚀🚀🚀🚀🚀🚀

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Knight

Knight

An entrepreneur with a decade of experience in building MEAN stack SaaS platforms.

More from Medium

Security Implications of Cloud Computing

Cloud Foundry Advisory Board Call, Mar 2022: Open Service Broker API

Dogfooding Testkube — Part1 — How to Test a Testing Framework — Kubeshop

Configuration Drifts and Ha