Database Security: Planning and Practices
Key Points
- Choose your database deployment (on‑premises, cloud, or remote) and evaluate the provider’s physical security, access controls, and whether you’ll be on shared or dedicated infrastructure.
- Isolate critical components (e.g., separate the database from the web/application server) to limit the impact of a compromise in a single layer such as the OS or PHP code.
- Verify that any SaaS or e‑commerce platform you use follows the same segregation and security best practices before trusting it with your data.
- Enforce strong, complex passwords and robust authentication policies, as weak passwords account for the majority of security breaches.
Sections
- Planning Secure Database Deployments - The speaker outlines key considerations for database security, emphasizing location choices, access controls, physical safeguards, and evaluating cloud provider and server‑sharing policies during development.
- Securing Services with Custom Ports - The speaker advises using non‑standard ports and configuring firewalls to allow only designated IP addresses for consistent, secure access across multiple servers and SaaS services.
Full Transcript
# Database Security: Planning and Practices **Source:** [https://www.youtube.com/watch?v=c3YaDqvSDrQ](https://www.youtube.com/watch?v=c3YaDqvSDrQ) **Duration:** 00:14:27 ## Summary - Choose your database deployment (on‑premises, cloud, or remote) and evaluate the provider’s physical security, access controls, and whether you’ll be on shared or dedicated infrastructure. - Isolate critical components (e.g., separate the database from the web/application server) to limit the impact of a compromise in a single layer such as the OS or PHP code. - Verify that any SaaS or e‑commerce platform you use follows the same segregation and security best practices before trusting it with your data. - Enforce strong, complex passwords and robust authentication policies, as weak passwords account for the majority of security breaches. ## Sections - [00:00:00](https://www.youtube.com/watch?v=c3YaDqvSDrQ&t=0s) **Planning Secure Database Deployments** - The speaker outlines key considerations for database security, emphasizing location choices, access controls, physical safeguards, and evaluating cloud provider and server‑sharing policies during development. - [00:06:58](https://www.youtube.com/watch?v=c3YaDqvSDrQ&t=418s) **Securing Services with Custom Ports** - The speaker advises using non‑standard ports and configuring firewalls to allow only designated IP addresses for consistent, secure access across multiple servers and SaaS services. ## Full Transcript
in today's world you must always be
security conscious but what does that
term usually mean as a technologist i
feel it can apply to many different
things hello my name is jamil spain
developer advocate with the ibm cloud
but when it comes to security i want to
specifically focus on the topic of
database security and to do this i want
to go through a few points which should
illustrate some thoughts to keep top of
mind as you start to plan during
development and definitely i hope you
take these into uh take these notice to
these topics especially at the end of
your project before it's time to go live
here
so the first topic that i want to talk
about is definitely where you're
planning your database to be on-prem or
another cloud another remote location
you should first think about the
user access to the system
as you know you can walk up to any
computer try to log in and actually
start typing things so if you're at home
or in an office make sure you have it
under a locked door
definitely and if you're
considering a cloud provider
they definitely must list out their
cloud procedures security uh protocols
they have in place who has access to
server rooms um and all these kind of
things pay special attention as well
whether you're on a shared environment
versus a dedicated kind of server
so two
very important things to keep in mind
here now secondly
if you're running a particular
application let's say you're doing a
lamp stack well which is common and most
stacks like that are common whether
you're dealing with lamp or the um
or the actual
mysql express
mongodb kind of situation
it's very useful to or convenient to put
all these components on one server but
what does that really expose you to
let's say you're doing a lampstat linux
apache mysql
php and there happens to be a compromise
we know from there there are two things
that can be compromised you have the
operating system
and maybe something in the php code
particularly a vulnerability that could
happen here so in the event that
something doesn't get compromised
another best practice to take into
consideration
is to have separation
and i'll just say of server here do some
shorthand code here so maybe you want to
run that on a separate machine
if
okay so it'll be separated so if in in
the event that something does happen
maybe at a linux os level
you have the ability that data is set
apart on another machine that you can
really isolate what happens there as
well this is especially important if you
have an e-commerce business occurring uh
for you
now if you are subscribing to a sas
service that runs your ecommerce
application do a little check out ask
some questions about do they have some
of these practices in place
next
let's deal with the actual access to the
system we talked about physical access
let's talk about user
now i believe if i can quote a recent
verizon survey is said that most almost
80 percent of of compromises are from
password selection so make sure you get
complex passwords
avoid the usual standard passwords that
are there one two three four five
really figure out some complexity of
characters numbers and special
characters and maybe increase the limit
out to at least be up to more than ten
characters uh really just just figure
out your complexity there what what your
policy should be in that use case
and then also
if you do have sensitive information
like we were just discussing
figure out what the context of the
application is if it is an e-commerce
application we do realize that at some
point you're going to have
sensitive data
and in those scenarios you want to make
sure you probably consider having some
encryption at rest if data must sit if
you must hold credit card information
make sure you actually plan out for how
you do your encryption and decryption
this is actually another way that most
will actually you leverage a third party
provider where you don't really have to
store any sensitive information
it can list on a third party service
which usually is already set up to be
compliant for security have those in
place so if you're not up to the
uh
the
particular situation of planning for
those contingencies please consider
using an outside service which is
already set up to use those and most of
those services will have proper ways
that you can pull data in and out
on demand as you need
usually normally through
rest apis here
okay let's move over to my next four
that we'll use
and so we talked about physical access
which users have access keeping
separation of those servers those
complex passwords and making sure we
have encryption there just in case data
must sit at rest
let's talk about the first next thing is
most database servers they have
uh published default ports
so you want to make sure that you
naturally these are things that most of
these databases can be run locally i can
stage them up pretty easily i know like
mysql is 3306 you have 27017
these are all common published ports so
anyone can research these
now in the actual cyber security world
alone most os especially linux there is
a popular utility you can use to run
scans on different vms over the internet
especially if you have a public ip
address so if i do a scan and it comes
up that 3306 is active
then it immediately lets me know you're
running my sql
database server on that actual server so
it really you want to kind of really
obfuscate
these particular details from being so
easily used and if you want to take that
concept way beyond databases we can also
use that for just normal ssh access you
know the standard port for that is 22.
we can probably run that on something
like
2222 you know something that's
non-standard so any of those services
that you want to go live with just do
your research and understand have a
strategy in place on ways that you can
use that and if you're using that across
multiple server servers let's say you're
managing a form of these
maybe it'll be a standard port that you
choose to run across those so everyone
always knows the pattern that you're
going to use now of course
for any of these situations whether you
want to change the port
most
servers if it's an os that you're doing
or we'll just talk about os's now so
you're doing a linux os they're going to
have particular firewalls that are
available here and with that you want to
probably if the goal is that you have
those separate servers and only there's
only one machine that will be
available to communicate with that
server
go ahead and put that server in as a
allowed
ip address okay
rather than standard by default most
services may come up and say access from
anywhere but if you only know the path
that must come in go ahead and set that
up so that happens now with a lot of sas
services you can also do the same thing
i know if i subscribe to a service like
on ibm cloud if i know that my remote
server is only coming from one i p
address that should be what you do only
allow those to come in all right and
maybe if you're working from your own
headquarters or a place that you do
development add in those ips as well to
come now i know what you're probably
thinking hey jamil it is kind of easy to
uh change your ip address but for those
individuals
you really must know what you're doing
to try to imitate other ip addresses uh
uh from what you um to it's not an easy
kind of hack to kind of do so
but for those there these additional
methods can really go in place to really
compound the effect uh that you can have
here
next
when you're running your database you
want to make sure you figure out how
you're going to do backups
especially when i started out with lamp
stacks it's easy to get this whole
configuration set up you can spin up a
vm at home or in the cloud for within
minutes maybe less than an hour and i
can quickly go yum or apt-get and
install the necessary packages to get
apache my sql and
your database and your programming
language install you can be off to the
races live build your site code it up be
live
but we want to make sure that we
actually are able to go through the
process of backing up and restoring all
right you want to be able to put this on
a regular schedule
when you will perform this activity and
most importantly in the situation that
you have separate servers and there is
an event of a a compromise there you
also want to make sure you have a copy
of your data all right that is all is
set up is secure and wherever you're
putting that to
the backups
the backup files at that
make sure that's in a place that is
encrypted all right so you may
definitely you want to if you can do
that extra step of complexity it's not
enough that i'm i have a separate
database server that i do backups on
regularly let's say every morning at at
midnight um or i mean not midnight let's
say 5 a.m 7 a.m whatever the the actual
cadence that you want to run that crime
job but do i really want to keep those
on the same server all right because if
someone is able to compromise that
server they can easily
unzip
uh back that up or maybe change data and
then restore that themselves all right
so definitely make sure you're keeping
those back up somewhere that you know is
safe and secure and if possible if
necessary take extra steps to make sure
that
those backups can be
encrypted in some way especially if they
maintain any sensitive information
and lastly i want to say is that we want
to make sure we're keeping
apps um
up to date
now this is not just for the different
database versions
we know that different vendors will
allow like well if you take my sql for
instance if i can pick on that for a
second
you'll see different versions come out
make sure you're in depth you get the
announcements for what's changed in
different versions as they come out make
sure that is applicable
for you so you want to make sure you
have a strategy for how you will upgrade
and that's usually involved there's
really not a concern there if you're
already planning for your backups being
able to stage a way that you can upgrade
your database server should be as easy
as backing up and restoring to a new
version with uh uh
just off the general principle of that
now naturally some versions may have
changes in underlying infrastructure or
or the way they're constructed from
different versions so you have to
account for that but usually that that
information will be actually documented
for you to use but i want to point out
one more thing here on our last note
here it's not just the actual
application
mysql database or the database versions
it's also any code
that you write you want to make sure
that those are up to date so let's take
for instance
i know um
you know i know it's probably you'll see
on the internet that uh let's take
wordpress for instance there are
thousands of plug-ins that are out there
i think a recent survey found that
at least more than half of those haven't
been updated in years all right so if i
have i may have my database up to date
secure with encryption backed up have
all my
walls covered but let's say i have
vulnerabilities in the application that
i'm running well if someone can gain
access to that application naturally
that will have connections to the
database and so it just opens up another
door that you don't want to have so on
top of that what i'm trying to summarize
here is that beyond having the actual
database at a certain version make sure
that all the code you write that's
accessing that whether it's a
pre-packaged application or something
that you're programming yourself has all
the necessary updates available just to
ensure that code that is accessing the
database there's no impersonation that
can happen there from someone gaining
access to that server
exposing vulnerabilities in the code to
to
actually get get to that
particular database
so
in summary these are just some tips to
consider
when you must kind of look at how secure
you are with your access to your
databases again this is a principle that
i like to think as a solutioning for
project at the start
definitely in the middle and definitely
before you go live in production so on
your next project please take these tips
into consideration thank you for your
time
if you have questions please drop us a
line below and if you want to see more
videos like this in the future please
like and subscribe