When cloud object
storage services were originally released, they focused on the functionality of
storing objects. At the time (and is frankly still good advice) the thought was
that identity is the new boundary, and that traditional network security rules
make cloud things complicated. The tag-phrase says something like
"Identity is the new boundary".
Over time, cloud
service providers have realized that customers want to be able to take PaaS
services and reduce the attack surface by limiting network access to those
resources. Providers such as AWS and Azure have answered the call by enhancing
their feature sets. As always, it is interesting to see the different
approaches taken. From an AWS standpoint, restricting network access occurs
(generally) as a condition of the authentication requests. In Azure, the
network restriction is surfaced as more of a "firewall" setting on
the service itself, and not necessarily tied to user access.
|
AWS
|
Azure
|
Internet IP
|
IP condition
|
IP rules
|
Deployed network
|
VPCE Condition
|
Virtual Network
Rules
|
Service
|
Service principles
|
Network exceptions
|
Let's talk a bit
about AWS first. Network restrictions on connections are enforced via policy
(usually at the bucket level). Another way to say this is that these network
conditions are surfaced as attributes of the authenticated request. IP
addresses and deployed networks are enforced via the condition statement in a
policy (aws:SourceIP and aws:sourceVPC). Services are defined in policies as a
principal.
In Azure, network
restriction setup is surfaced more as a list of firewall rules with special
conditions. You can add up to 100 network or IP rules to a given account.
Service endpoints are required to enable private access from a virtual network
to a storage account. Once enabled, the virtual network will appear in a list
of eligible virtual networks for access. On the service side, Azure uses the
concept of "exceptions" which allow network access from a list of
approved Azure services (which you can control).
From a network
response perspective, the two services tend to return different codes for
different situations.
For example,
accessing blobs that don't exist in Azure result in a different 404 code
depending on the access granted.
Here is an example
of a return code when the file doesn't exist but the container is publicly
accessible:
And
here is an example of when a file doesn't exist and the blob is NOT accessible
to the public.
Notice the
difference? From an AWS perspective, you just get a cold/hard 403 in both
cases.
No comments:
Post a Comment