Is there a future in IT?

[TheGuy]

lol

I tend to discard CVs that have MCSE on them


Minesweeper Champion, Solitaire Expert!

I only have an MCSE and I'm not doing too badly.

 

[me_]

I really don't see how they can have better uptime.
Economies of scale, for a bank, again doubtful but at best it will be really close

Sorry, I used the wrong term. Uptime would most likely be lower than a cloud provider, but Availability is higher. Availability is the Actual uptime as a percent of planned uptime.
Most applications / services are not required 24/7. This means there are decent maintenance windows in which to perform higher risk activities. Where I work now, we are able to achieve 5 9s most years. Over the last 3 years, we have an average of 5 minutes unplanned downtime per server per year.
For cloud providers, they are 24/7 and very often support businesses across a number of time zones. This means it's always a critical window for someone when they perform a change. Also, cloud outages often take longer to resolve due to the increased complexity of scale (as in the Azure Australia outage last year which took 7 hours to restore services).
This is baked into their SLAs - most services are offered with a 3 9s availability per year (+- 9 hours per year) or 2 9s per month (+- 7 hours per month). This means Azure's 7 hour outage in Australia would be within SLA for most services as long as they don't have another outage in the year. These long SLAs would necessitate running a disaster recovery set of servers on a separate cloud provider (loss of critical services for more than 4 hour would be classified as a disaster).

Furthermore, our least reliable infrastructure is our internet connection. Even with multiple redundancies and guaranteed bandwidth, we have still had a few incidents where we have been left without any internet connection or running in a degraded state affecting some cloud services we use. Over the last 3 years, we are sitting on approximately 1.5 hours unplanned downtime per year for internet services.

 

[Gnome]

Firstly, don't confuse high availability with disaster recovery. The replications for your main data storage should not be used for backups and retention. This was the very problem with Code Spaces who had all their data and backups on AWS and it was all wiped in a hack - they had no offline backups for disaster recovery so they went under:
https://threatpost.com/hacker-puts-hosting-service-code-spaces-out-of-business/106761/

They put all their data in one s3 bucket and hoped for the best.

A lot of institutions are moving to disk based backups which would use a set of servers where the primary serves regular backups and ships to the secondary, but where deleting the data on the primary would not remove old backups from the secondary.
Even with this, they still often use tape backups to ensure there is a completely offline copy somewhere. No critical data would be backed up on only 1 tape. Usually it'll be stored online for 18months - 36months and would be on a full backup every month so there would be a number of tapes that could be recovered. Furthermore, it is standard practice to spot check tapes to ensure recovery.

S3 also offers long term storage options and you can also disable some actions by contacting the support, eg. delete.

Financial institutions also need to deal with different data sovereignty and legal issues which means it's usually not allowed to store data on all locations available from the vendor. For example, no data can be stored on US based servers due to their legislation around jurisdiction and ownership of data.

You can store the data in many different regions in the world.

 

[Gnome]

I was suggesting that relying on SSL and the internal cloud encryption is insufficient. The problem is that the cloud provider stores both the encrypted data and the key.

This really depends on how you created your application.
I wouldn't store my keys in AWS, nor would I rely on AWS KMS.

This means that if a user account is hacked (like in the case of the iCloud hack) then the data is exposed.

Making an AWS account hack proof is really, really simple.
You can disable root keys.
Only allow credentials that have very, very limited access.
Only allow admin login with a physical security token or two factor auth or if you call in, etc.

The company you mentioned before used their root keys on their applications.
You have to admit, this is beyond stupid.

If a financial institution were to share data, I would advocate for a no knowledge type setup where the data is encrypted on the client. Then SSL and everything else becomes irrelevant and even if a user account is hacked, the hackers will not be able to read the data.

Agreed