Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Missing Authentication between Microservices #4107

Open
prernaadev01 opened this issue Sep 2, 2024 · 0 comments
Open

Missing Authentication between Microservices #4107

prernaadev01 opened this issue Sep 2, 2024 · 0 comments
Labels
Priority P2 Medium Priority

Comments

@prernaadev01
Copy link
Collaborator

Impact

An attacker able to access an internal service could impersonate other services, intercept or modify data in transit, and perform unauthorized actions, compromising the integrity and security of the entire application.

Description

Discussions with Envision Blockchain revealed that the internal communication between microservices did not require authentication. This meant that any resource capable of communicating with a given service could execute actions on that service without authentication. Such a setup significantly increases the risk exposure for the environment. If any resource within the system is compromised, an attacker could potentially gain access to any other resource within the system without needing to authenticate, posing a severe security threat.
As an example, any compromised service could be able to access or inject malicious messages in the message broker to execute arbitrary actions within the system.

Recommendation

It is recommended to implement mutual authentication for all internal microservice communications to ensure that each service can verify the identity of the other.
It is recommended to ensure that each service is properly authenticated, using authorization roles and permissions to ensure that each service can only publish or consume messages in the queues relevant to its designated function.
Moreover, messages could be digitally signed, ensuring they originate from the correct service. At each step in the process, the signatures can be verified to ensure that the message has not been tampered with.
Where applicable, integrate these recommendations into the security hardening guide to ensure organizations deploying the application can implement these best practices effectively.

Location

• guardian-service
• notification-service • logger-service
• worker-service
• auth-service
• ai-service
• policy-service
• application-events • topic-viewer

@prernaadev01 prernaadev01 added the Priority P2 Medium Priority label Sep 2, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Priority P2 Medium Priority
Projects
None yet
Development

No branches or pull requests

1 participant