Microservices architecture is more dispersed in nature hence, there will be a larger surface area for attacks and vulnerabilities. But because of this dispersion where services being independent at one another, this architecture allows for a more granular restrictions.
Reference: Packt's Hands-On Microservices with Python by Peter Fisher
- At the infrastructure, the concern is coming from multiple network entry-points, rate limits and traffic throttling configuration, need for multiple firewalls, defense in depth, network structures and keys and tokens management.
- Ensure regular updates taking note of the following:
- updates must not break the system
- updates should not interrupt the application
- updates must not require full deployments
- Keep control
- never assume infinite scalability
- rate limits protect from DDoS
- always test your load
- Keep your guard up
- multiple firewalls
- minimum exposure (expose only what is needed)
- keep sensitive services private
- Keep/protect your keys
- do not store in the servers
- encrypt everything
- use internal and changeable tokens like OAuth
- Application concerns
- repeatable deployments
- encryption algorithms
- protection methods depending on data types
- security configuration
- testing (white, black and penetration)
- Data concerns
- input validation
- output encoding
- not obvious ID's
- end-to-end encryption
- authentication and authorization even among services
- To mitigate both application and data concerns
- don't make the data structures obvious
- keep IDs out of API endpoints
- it is recommended to use OAuth for authentication and authorization
- usually done in API gateway which enables service discovery
- enables: role based access, access control and signed requests
- helps with orchestration
- provides caching layer
Reference: Packt's Hands-On Microservices with Python by Peter Fisher