Every desktop has individual credentials for the local user, and except when unavoidable, you don't grant any network users (LDAP, etc.) any access.
This means no central provisioning of user accounts/etc. That is a non-starter in any big company.
Lots of big companies do this. It isn't a non-starter except in the minds of people who have always done it in a particular way.
Anytime anybody needs access to another PC you have to send out an IT guy to grant access.
Why would anyone ever need access to another PC? Each employee should have a machine, and nobody else should be touching it unless that employee leaves the company, in which case the exit interview should require them to set their password to something and give it to their manager. So the only time you have to send an IT person out to grant access is when an employee dies suddenly.
Oh good - so that when the building catches on fire you lose the backup too. If the PC doesn't contain anything valuable, it doesn't need backup. If it does need backup, it needs something better than an external hard drive. Security isn't just about denying access to strangers - it is also about ensuring access to those who need it.
Fires are exceptionally rare, and the truly high-value assets should be on servers, which as I mentioned, should be backed up off-site, in an individually encrypted fashion. You can do this for desktops, too, if you'd prefer, but in practice, this really isn't needed.
This is a big company. Everything is a shared project, and everything needs all that backup anyway. Now the user has to remember multiple sets of credentials since they need a different password for every thing they work on since there are no network credentials in your firewalled paradise.
There's no reason you can't use the same password. That's really no different than using a shared credential, security-wise, except that a shared credential database represents a single server that you can target to obtain information for all servers, whereas per-server credential databases contain a smaller subset of accounts, which means that cracking one machine and stealing its password database will gain you access to fewer machines than cracking that central password server would.
Oh, you need to have one dedicated hardware box for every project - no VMs in your IT paradise.
Why not? There's nothing preventing a VM's hard drive from being encrypted, and if somebody gets and keeps kernel access to a server long enough to find the keys in memory, you're in deep crap anyway.
Looks like you need a dedicated backup box for each one too, since we don't want to have one backup box with credentials to thousands of servers. I guess the guys who change the tapes keep a big paper list of all the backup server passwords. Oh, and I guess you buy an LTO tape drive for each server too. :)
Nope. I specifically said that you should encrypt the backup data. The backups can all be stored remotely on a single server, or pushed to a single tape drive, just so long as the data is encrypted by the machine that is being backed up. That's the only way to prevent your backup system from being a single attack surface that gains you access to everything.
And of course there are no central credentials of any kind, and likely no way to recover lost keys for all those encrypted emails.
Realistically, why would you ever need to do that? Any internal email of value is, by definition, in the account of more than one person. The chances of an entire department dying in a catastrophic accident are very, very low.
There is a reason that no big company has policies like these.
The last company I worked for had many of these policies, minus the email encryption, with network credentials for servers *only*, and without the aggressive network monitoring. Its market cap is larger than the annual budget of many entire countries. So what I've suggested isn't really that much of a stretch.
And a zero-day exploit is very much a possibility all the same, which would mean that the hackers are the only people who can actually remotely administer all your PCs.
A remote zero-day exploit is remarkably rare. Realistically, zero-day exploits almost invariably involve bringing in outside content, and you have the ability to filter outside content. Either way, the means in which I proposed to restrict communications is such that it would only rarely affect users, but it would quickly detect any command-and-control channels so that they can be closed in a timely manner.
I don't mean to pick on you. It just sounds like you're proposing putting an end to social engineering attacks by removing all the telephones from the workplace. The reason those computers are all networked in the first place is that they help everybody to get work done.
Not at all. More like putting an end to social engineering by noticing that ten employees were called by an unknown number, and asking the employee who it was. But even that isn't quite accurate. Unlike with a phone system, in practice, computers in a workplace are almost never accessible from the outside world without a VPN connection. So by definition, any command-and-control communication channel must be opened from the inside to an external server. And you should be able to determine whether the user initiated that communication with a fairly high degree of certainty by making the browser tell you. Given how few distinct servers an average computer communicates with beyond the user's knowledge (mostly limited to automatic updates), it should be very easy to identify any command-and-control connections, because they're the connections that the browser didn't initiate, but that go to a server you don't recognize.