BSIT400 Cloud Computing and Governance

One of the things I like about the prospect of using cloud systems is the ability to build infrastructure from code. Typically, it can take infrastructure teams days or weeks to provision systems for development teams to use. With infrastructure as code, this can be built in minutes! With infrastructure as code, using standard written configs, a set of servers to assist the teams can be brought up or destroyed as needed. This helps teams that are trying to be more agile. When looking for bottlenecks in a process, infrastructure is usually part of the problem. With infrastructure as code, this is solved and gives infrastructure teams a new skill to help with on-premises management as well.

There are a couple of reasons why monitoring systems in the cloud is important. The first, and most obvious, is to ensure systems are still up. Sometimes, building systems in the cloud doesn't get the same attention as physical datacenter systems. It is important, even in the cloud, to make sure the resource allotments are right and systems are up. The other thing that needs to be monitored is utilization for billing. In the cloud, when services are built to be billed by consumption, those costs should be monitored. This is different from on-premise systems, where the resources are bought in advance and no further unexpected utilization costs are incurred. To make sure the enterprise doesn't incur surprise costs, the services should have a quota or limit. The other thing that this helps with is turning down underutilized systems so that no additional costs are incurred.

Something I have been curious about for a while, and it came up again this week, is data deduplication. For my on-premise data centers, we always run dedupe and compression on the systems to squeeze more out of the raw hardware. I wonder how much cloud service providers can deduplicate data across customers, though. Surely they have to be able to do it at scale to make the business model work in their favor. Based on an article from Microsoft this week, some deduplication can get as high as 95% efficiency. This is a specific file type for consumers, but do CSPs run the same algorithms? There are also providers, like Box.com that don't even charge by how much data you store with them. It is all about user licenses with unlimited capacity to store data. I think they have to have some way of gaining massive optimizations across users to make that work. It must be about the scale at the end of the day.

When talking about root accounts, I think it is important to acknowledge their purpose and how to protect them. Root accounts usually can't be deleted outright, and that isn't a bad thing. Having a root account be a break-glass account is beneficial when a system like directory services or SSO isn't working. They are sometimes critical when an incident happens and immediate access is needed. Knowing that they can't be removed, my goal is to know every time they are used. I like to have security systems tied to these platforms to get an alert when someone has needed to use the root account. This gives the administrators flexibility to do their work, but also holds them accountable for following a process. The key to this is having well-documented root account names and a log aggregator like a SIEM with alerts set up for authentication attempts.

One of the most interesting network accomplishments I have completed in my career is getting a Fortigate firewall appliance provisioned in the cloud. Cloud security has not always been intuitive and there are many vulnerabilities that are exploited because systems are left exposed unintentionally. To overcome this challenge I decided to provision the same type of firewall we used on-premise in the cloud. The challenge was provisioning the cloud appliance. Fortinet had images on their market that could be pulled for the appliance, but in the provisioning phase we needed to apply all the resources needed up front, including cores, memory, interfaces. We did have to do this a couple of times to get it right and figure out the ordering of deployment. Once the appliance was up it was only a matter of getting the Vnet tied to the appliance interfaces and set up routing tables to create defined internal and external networks. After it was completed we could build an IPSec tunnel from the clou...

A newer concept to me is the VXLAN. I have heard of spanning VLANs over layer3 networks, but it is typically an expensive endeavor that has never made sense to me in the past. Using VXLANs where the MAC is inserted at layer 4 instead of layer 2 to create an overlay network seems like it might be a better option where broadcast domains need to be joined. The thing that I don't like doing in my own networks, though, is relying on broadcast or flat network dependent traffic. Usually my experience has been that this dependence is related to poorly developed applications. This might be changing, and it would be interesting to know if companies are using VXLANs more or if security best practices are changing in a way that allows this to be a standard. One of the things I have seen changing a little is better endpoint security, where the network layer isn't the most prominent place to protect systems. EDR has brought a lot of security down to the host. If this trend continues, the mor...