BSIT400 Cloud Computing and Governance

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...

Something interesting when looking at subnetting in the cloud is the amount of translations that need to happen in the backend for everything to work. With the numerous customers that a cloud service provider like AWS would be hosting, there would need to be the ability to have completely isolated, but still routable RFC1918 networks sitting beside all their other customers. When looking through the AWS documentation there doesn't seem to be a limitation on what IP addresses can and can't be used, and as I have spun up my own networks it is very flexible. Multiple layers of routing need to happen for this all to work. The customer routing, the datacenter infrastructure routing, AWS internal routing, and their connections to the outside world. Since AWS allows customers to provision their own networks, this has to happen seamlessly in the background using templated provisioning. It would be a wonder to see what this architecture looks like and how AWS can keep up with it.

When looking at the stages of cloud migrations, I think the planning phase is the most important phase to spend time on. Planning consists of designating which workloads make sense in the cloud, which cloud services will replace servers, the correct resource allocation, and an estimate of costs. The reason this phase is so important is because it will determine how successful a long-term stay in the cloud will be, or if the company is likely to be migrating back to on-premise. There are a couple of different reasons for moving to the cloud, with two of the big reasons being cost and scalability. For cost, a business case can be put together from the results of planning the migration and what it would take to move systems to the cloud. Too often the costs are not well known and when in the cloud it can quickly get out of control when not managed properly. Planning for each costs and using the assistance of a migration partner that excels in this area can set realistic expectations for m...

I have been at several companies that made the move to the cloud when it was beginning to peak in popularity. Migration tools and free consultants made it easy to move our servers to the equivalent Azure virtual machines. When moving services to the cloud there is always a time at the beginning when the costs are cheap and the full scale of the bill hasn't fully hit. It takes a little while for the costs to settle. Unfortunately, this type of migration isn't sustainable. These same companies I have seen move to the cloud very quickly decide they need to move back to on-premise data centers. As I have watched this happen it has formed my opinion to be that using virtual machines in the cloud is not cost-effective. While short-term utilization of virtual machines is nice to do development and testing, cloud services should be prioritized over cloud servers. By adopting cloud services, admins get the most cost-effective solutions that can scale. This means that instead of migratin...