The penetration testing report showed that (page 44):
A number of resources were found to accept connections from clients on any network, including the Internet. Although this is the default Azure configuration, it could allow the resources to be accessed by an attacker who has obtained valid credentials by another means.
Upon reviewing the configuration of resources via the Azure Portal, it was identified that a number of resources were found to permit public access to resources, such as Azure KeyVault and Storage Accounts.
Despite enablement of Private Endpoints, which provision resources with an internal IP address once deployed to a Virtual Network, some resources still permitted public access. As such, it is likely that private access may be redundant for at least some resources.
N.B. In some cases, this may be due to manually enabling access after the SDE was deployed, so we could debug issues. However, this should still be reviewed, and access only enabled for supported networks, such as Barts internal.
The first step is to review and classify the resources that are (potentially) exposed. Some are already behind firewalls, others are non-SDE but still potentially sensitive. Either things are fixed, or tickets are filed to fix them later, or the reason for accepting the risk and not fixing it is documented. In some cases, we may implement a fix, but not soon, so that must be captured.
This is a medium level risk, but is something we must fix before the next pen-test.
The penetration testing report showed that (page 44):
A number of resources were found to accept connections from clients on any network, including the Internet. Although this is the default Azure configuration, it could allow the resources to be accessed by an attacker who has obtained valid credentials by another means.
Upon reviewing the configuration of resources via the Azure Portal, it was identified that a number of resources were found to permit public access to resources, such as Azure KeyVault and Storage Accounts.
Despite enablement of Private Endpoints, which provision resources with an internal IP address once deployed to a Virtual Network, some resources still permitted public access. As such, it is likely that private access may be redundant for at least some resources.
N.B. In some cases, this may be due to manually enabling access after the SDE was deployed, so we could debug issues. However, this should still be reviewed, and access only enabled for supported networks, such as Barts internal.
The first step is to review and classify the resources that are (potentially) exposed. Some are already behind firewalls, others are non-SDE but still potentially sensitive. Either things are fixed, or tickets are filed to fix them later, or the reason for accepting the risk and not fixing it is documented. In some cases, we may implement a fix, but not soon, so that must be captured.
This is a medium level risk, but is something we must fix before the next pen-test.