I would like to make sure at-rest encryption is done in one place and correctly. If there's shared storage, that seems like the right place rather than DAS.
Mainly I'd like to cover the case of drives being recovered without keys and the keys be required when the SAN boots (should be a rare event to not be a pain but also cover the case of someone stealing the whole kit and caboodle).
To attach to the SAN you need iSCSI (with credentials) or be on the FC switch.
This seems like it would cover database and NAS cases.
What's right or wrong with this?
Certain models of Storage Subsystems support full disk encryption, allowing your data to be encrypted while at rest on disks. The encryption keys are either stored on the subsystem controllers or an external central store.
The ones I'm familiar with are from IBM - the DS5000 / DS8000 series. The DS5000 controllers store individual security keys for each drive - one would need to remove the entire controller and drives in order to gain access to the data. Probably not something most companies should be worried about in a risk analysis.
Beyond that, the DS8000 architecture uses an external keyserver to store all the drive encryption keys. This model gives what you ask for - you can set it up to require a password to unlock the central master keystore, but storage subsystems / tape libraries that use it can authenticate and gain access to their encryption keys without intervention.
You can read more about the IBM technology here.
Physical security would be so much easier than encrypting the whole SAN, not to mention the performance hit from constant encryption (or hardware costs for something approaching transparency at SAN throughputs).
We've done some lab implementations of a Linux-based iSCSI target with LUKS/dm-crypt-encrypted disks with the capabilities you describe - when started, a key needed to be provided to unlock the encrypted slot.
Compared to the self-encrypting drive approach leveraged by several storage vendors (including LSI and IBM as pointed out by MikeyB) it has the advantage of encrypting data before it is sent to the controller, thus also covering possible electromagnetic emission eavesdropping scenarios. And it suffers the obvious disadvantage of being self-made and unsupported. Sun/Oracle Solaris-based storage would theoretically allow for a similar setup using Zfs encryption features - would be worth asking there whether this is a supported scenario.