AWSvAzure - Object Storage - Network Access

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.