AND (not but) using the +1 (or +n) spare physical machine policy as per MOSES,
the nifty thing is to rebuild all the VMs for a physical server set and then do
a swap, making the outage window approximately the same amount of time as
refreshing network address widgets (if any). IF the database "instance"
availability is on two or more separate sets of physical servers on which the
VMs are built, this *could* facilitate true no-bounce operations, where *could*
means you need to get a pant load of other things between the users and the
database built to at least not prevent new logons or service requests or
(harder) fail-over things in flight.
This does wreak havoc IF persistent storage media is literally plugged into the
physical machine bus or backplane rather than a multi-port device or
non-physically detachable device. So as usual, your mileage may vary. This is
probably irrelevant to mass market solutions anyway.
It's plausible that application servers can be rebuilt to field new sessions
very frequently while I tend to thing Tim's once a week goal for database
servers is achievable and probably sufficient, especially if only trusted
connections can be made to the database servers. If the standard environment
prevents untrusted connections, then exceptions to the standard might trigger a
rebuild apart from the standard schedule.
Good luck.
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On ;
Behalf Of Tim Gorman
Sent: Monday, March 07, 2022 11:45 AM
To: oracle-l@xxxxxxxxxxxxx
Subject: Re: MS Defender for OL7 Oracle DB servers
Scheduled automated VM rebuilds work just fine with multi-TB databases, on-prem
or in the cloud. Data storage is detached from the soon-to-be-destroyed VMs,
then re-attached to newly-rebuilt VMs and binaries. Don't confuse a
requirement to rebuild code and systems with a requirement to rebuild data.
Certainly there is a possibility that the very tools used for security become
an attack vector; that is the whole point of the exercise, by forcing a small
number of carefully scanned and trusted images to be propagated throughout. If
one can't automate rebuild, then one is stuck with predominance of
ever-more-fragile house-of-cards with undetected malware festering within
indefinitely.
Think it through, think of alternatives, and think a couple moves ahead...
On 3/5/2022 4:33 PM, Mladen Gogala wrote:
On 3/5/22 15:44, Tim Gorman wrote:
Just a heads-up as to where (I think) the world is heading...
Years ago, I was working at a large US telecom, and one of the goals
of their virtualization efforts (i.e. moves to VMs on-prem, moves to
containers, moves to cloud, etc) is to enable themselves to rebuild
every virtual machine from a trusted image every week.
If a VM becomes "infected" with anything, then that will last for
only a finite period before it is wiped out by a scheduled automated
rebuild, if it is not detected sooner and then wiped out by a
manually-initiated automated rebuild.
This doesn't mean that other preventative or protective efforts are
reduced in any way, just that this is a last protective measure, for
when all else fails. And, as we know, all else will indeed fail,
eventually.
Back then, they included a requirement for automated rebuild from a
trusted image to be scheduled every 6-9 months for all newly-built
infrastructure. As their skills improve, the stated plan was to
gradually reduce the scheduled frequency from 6-9 months down to one
week.
So, if you're wondering about your organization's push to automation,
to virtualization, to containers, or to cloud, then it's not
necessarily because these things are "shiny" and "new", or somehow
less expensive in themselves. It is because these technologies are
seen as stepping stones to a possibly-as-yet-unstated goal in the
never-ending arms race of infoSec.
Well, I am not so sure how would that function with a terabyte sized
database in the cloud. Also, there is a very real possibility (see
SolarWinds) that the tools used for monitoring network would be used
as an attack vector. The only thing that can prevent the data from
being stolen by a rogue actor acquiring access rights is encryption.
And we don't encrypt nearly enough data. Also, phishing attacks are
getting more and more sophisticated. The good old times of a Nigerian
prince in need of bank transfer or "winning Microsoft lottery" are
long gone. Acquiring credentials is easier than ever, unless MFA is
used. The problem isn't infecting the server with anything, the
problem is data theft. Your database server doesn't necessarily need
to be infected with anything. The tables ACCOUNTS, CUSTOMERS and
ADDRESSES can be dumped to CSV files using a script and the damage is
done.
Unfortunately, MS Defender doesn't do nearly good enough job to
protect your servers. And neither does any other software. I have
recently received several quite well crafted spear phishing attempts.
No warning from MS Defender or McAffee. The only real defense is our
security awareness.
--
Mladen Gogala
Database Consultant
Tel: (347) 321-1217
https://dbwhisperer.wordpress.com
-- //www.freelists.org/webpage/oracle-l
