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, take
these notice of these topics,
especially at the end of your
project before it's time to go
live here.
For the first topic that I want to
talk about is definitely where
you're planning your database
to be on-prem or in 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
protocols they have in place, who
has access to server rooms
and all these kind of things.
Pay special attention as well,
whether you want 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,
or the actual MySQL
Express, or MongoDB
kind of situation is 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 LAMP stack,
Linux, Apache, MySQL, PHP.
And there happens to be a
compromise, we know from there that
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
does 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,
diff.
OK.
So it'll be separated, so if 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 for you.
Now, If you are subscribing
to a SaaS service and run your
e-commerce application, do
a little checkout, ask them
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
it 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 or 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 10 characters.
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 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
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.
OK, let's move over to my next
four that will 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 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 Mongo, 27017.
These are all common public ports,
so anyone can research these.
Now, in the actual cybersecurity
world alone, most OSs, especially
Linux, there is a popular utility
you can use to run scans on
different VMs over the internet if
especially if you have a public IP
address. So, if I do
a scan and it comes up that 3306
is active, that immediately
lets me know you're running
MySQL database server
on that actual server.
So, it really, you want to kind
of really obfuscate these
particular details for 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
22222, you know, something that's
nonstandard.
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 using it across multiple
server servers, they say you're
managing a form of these,
maybe it'll be a standard port
that you choose to run across,
though, 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 will just talk
about OSs 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 had
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 an allowed
IP address.
OK.
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 SaaS 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 IP 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 what you're probably
thinking, "Hey Jamil, it is kind
of easy to change
your IP address", but for those
individuals, you really
must know what you're doing to try
to imitate other IP
addresses from which
you 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 that you can have
here.
Next,
when you're running your database,
you want to make sure you figure out
how are you going to do backups.
Especially when I started out with
LAMP Stacks it's easy to get
this whole configuration set up.
You could spin up a VM at home
or in the cloud within minutes,
maybe less than an hour, and I
can quickly go Yum or apt-get
and install the necessary packages
to get Apache, MySQL and
your database and your programing
language installed.
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 this
situation that you have separate
servers and there is an event
of 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 in a place that is
encrypted, all right.
So you may definitely you want
to if you can do that, extra
step of complexity is not enough
that I have a separate database
server that I do backups on
regularly. Lets say every morning
at midnight, or
I mean not midnight, lets say I will
say 5 AM, 7 AM, whatever
the actual cadence that you want to
run that Cron 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
and back that up or
maybe change data and then restore
that themselves.
All right. So definitely make sure
you're keeping those backups
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 up
to date.
Now, this is not just for the
different database versions.
We know that different vendors will
allow like what, if you take MySQL
for instance, if I can pick on that
for a second, you'll see different
versions come out.
Make sure you're in step, 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 already plan
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
just off the general principle of
that. Now, naturally, some versions
may have changes in underlying
infrastructure 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
is 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 who
are up to date. So let's take, for
instance, I know,
you know, I know it's probably
you'll see on the internet that
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
having 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 is
accessing that.
Whether it's a prepackaged
application or something that you're
programing 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 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 solution
for project at the start,
definitely in the middle and
definitely before you go live in
production.
So in 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.