What is it with cloud computing? Engage VM, disengage brain?

Nine bits of advice from our man Trevor


1. If your data doesn't exist in two places, it doesn't exist

Always make backups of your data, and keep one of those backups somewhere that is not where your primary data is kept.

If you keep your primary data on premises, get a disaster recovery (DR) site, or encrypt your backups and send them to a cloud provider. If you already use a cloud provider, back up your data to a different cloud provider. Under no circumstances back your data up to the same cloud provider as is running your primary workloads!

2. Never use the same username and password for multiple accounts

Make damn sure the bad guys can't get all copies of your data by compromising a single provider, be that a cloud provider, or your local network. What good would using one cloud provider for primary workloads and one for backups be if you used the same username and password for both? What good is a DR site if getting hold of the domain administrator's username and password unlocks all the treasure boxes on both sites?

3. Use multi-factor authentication

Yes, those stupid key fobs or Google authenticator are annoying. I hate them too. Use them anyways, we don't have anything better.

4. Fear lock-in

If, under duress, you can't arrange to leave behind your existing infrastructure provider in a week, you're in a bad place. Whether that infrastructure is local, or it's cloud-based, you need to know enough about backing it up and restoring it that you can take the whole kit and caboodle and move it on short notice. You just may have to.

5. Don't just plan backups, plan restores

So you used cloud storage as a cheap disaster recovery storage location. Then disaster struck. Can you get your data back and be operational again in time to save the business, or are you going to be trying to suck 40TB through an ADSL modem? Never underestimate the bandwidth of a truck full of disks. Consider a colo facility or a truly local cloud provider before you consider the majors. They may be able to put your data in a car and drive it over to you if you ever need it.

6. Monitor everything

Don't just check to see if your site is up or down. Make sure you use cloud providers or in-house security systems that can tell you how many times an administrator has logged in, and from where. Actually check these things.

7. Always assume everything is compromised.

The days of "eggshell" computing – where you defend only the perimeter and leave everything behind the edge firewall wide open – are behind us. Always assume every single system you operate – on your own premises or in the cloud – is compromised. If I compromise the administrative account on that server, how many others can I attack? What information can I steal? How will you ever know if a breach has occurred? Learn to compartmentalize.

8. Make sure you have enough staff; pay and train them well

Clouds – public or private – aren't an excuse to fire a bunch of people, or attempt to make existing staff do more. The public cloud means that your administrators face a whole new set of challenges. You want them to provide a stable, reliable, secure service that can withstand both malice and incompetence. Don't ask them to work for a pittance, pay for their own training and do it on their own time.

9. Pay for appropriate hardware, software and services

If you run all your stuff locally, or in the public cloud, you still need to buy the right gear. A public cloud play will require – at a minimum – backups, monitoring and security auditing from a company other than the one you use for your primary cloud service. Running your workloads on premises could require pretty much anything. Don't cheap out. It could cost you your business.

Next page: The cake is a lie

Similar topics


Other stories you might like

  • If you're using the ctx Python package, bad news: Vandal added info-stealing code
    Domain associated with maintainer email expired, taken over in supply-chain attack

    The Python Package Index (PyPI), a repository for Python software libraries, has advised Python developers that the ctx package has been compromised.

    Any installation of the software in the past ten days should be investigated to determine whether sensitive account identifiers stored in environment variables, such as cloud access keys, have been stolen.

    The PyPI administrators estimate that about 27,000 malicious copies of ctx were downloaded from the registry since the rogue versions of ctx first appeared, starting around 19:18 UTC on May 14, 2022.

    Continue reading
  • DigitalOcean sets sail for serverless seas with Functions feature
    Might be something for those who find AWS, Azure, GCP overly complex

    DigitalOcean dipped its toes in the serverless seas Tuesday with the launch of a Functions service it's positioning as a developer-friendly alternative to Amazon Web Services Lambda, Microsoft Azure Functions, and Google Cloud Functions.

    The platform enables developers to deploy blocks or snippets of code without concern for the underlying infrastructure, hence the name serverless. However, according to DigitalOcean Chief Product Officer Gabe Monroy, most serverless platforms are challenging to use and require developers to rewrite their apps for the new architecture. The ultimate goal being to structure, or restructure, an application into bits of code that only run when events occur, without having to provision servers and stand up and leave running a full stack.

    "Competing solutions are not doing a great job at meeting developers where they are with workloads that are already running today," Monroy told The Register.

    Continue reading
  • Patch now: Zoom chat messages can infect PCs, Macs, phones with malware
    Google Project Zero blows lid off bug involving that old chestnut: XML parsing

    Zoom has fixed a security flaw in its video-conferencing software that a miscreant could exploit with chat messages to potentially execute malicious code on a victim's device.

    The bug, tracked as CVE-2022-22787, received a CVSS severity score of 5.9 out of 10, making it a medium-severity vulnerability. It affects Zoom Client for Meetings running on Android, iOS, Linux, macOS and Windows systems before version 5.10.0, and users should download the latest version of the software to protect against this arbitrary remote-code-execution vulnerability.

    The upshot is that someone who can send you chat messages could cause your vulnerable Zoom client app to install malicious code, such as malware and spyware, from an arbitrary server. Exploiting this is a bit involved, so crooks may not jump on it, but you should still update your app.

    Continue reading

Biting the hand that feeds IT © 1998–2022