in this lesson, you’ll see a summary of the security topics covered. It’s very important to ensure that ScyllaDB runs in a trusted network environment, limit access to IP / Port by role, use the minimal privileges principle, avoid Public IP if possible and use VPC if possible. Security is an ongoing process, make sure that you routinely upgrade to the latest ScyllaDB and OS versions, routinely check for network exposure, routinely replace keys/passwords, use 2FA (ScyllaDB Cloud), and use the minimal privilege principle, apply available security features.
The most basic security feature you want to enable is just minimize your network
exposure, that’s the most basic and most efficient things, you want to
make sure that external server that can connect to the database will only
be able to do that over CQL for example, you don’t want to give SSH keys
or something like that to everyone if you can use a private
IP not public IP much better and nothing here is specific to ScyllaDB
everything you know everything from other system and this is the diagram of
all the ports used by ScyllaDB, I think it’s all of them including the monitoring
and manager, so the best practice and by the way we are doing the same on ScyllaDB Cloud
we have a ScyllaDB Cloud session later today, everything that I mentioned here
we apply it ourselves for the cluster that we manage and this is the most
important one so for example we are using a port 7000/7001 for
connection between the nodes for the interconnection between the nodes
exchange data between nodes, so no one else need to have access to this port
outside of ScyllaDB nodes, okay so and you should validate it routinely so if for
example the monitoring server shouldn’t have access to this port
your application shouldn’t have access to this port and the same go for
other ports, for example the nodes do not need to have CQL access over 9042
between them, they are not using that so the best will be to create
a firewall rule or if you’re using AWS it will be a security group and define all
of those parameters in a way that you limited your access just to valid IP
and valid ports and by the way it’s on many system and I saw it in the past
you are doing it in an installation and after a month, two months someone
add a node, someone change configuration and such and by mistake exposing IP
or exposing ports so there are, I’m not going to recommend specific products or
specific project but there are tools out there to validate exposure, there are
tools of course to manage configuration and it’s recommended to use those to
control these kind of parameters. For. ScyllaDB Cloud, we have a full session on
that but the same go for ScyllaDB Cloud for when you launch a cluster in ScyllaDB Cloud
you need to specify the range of IP that the Cloud server open to, try to
minimize it as much as possible if you can use VPC Peering and drop all
public IP, even better, just by dropping the public IP of your cluster
you already took a huge step in securing your cluster. I don’t know if
you guys are familiar with Shodan? Who is familiar with this cool site?
No one? – well you should, so you can visit this site, it’s like a Google of security
problems, so you can go to this site write – ScyllaDB, Cassandra, MongoDB or
some kind of IoT name – a camera and it will just show you all the exposed
databases in the Internet and you’ll be shocked and surprised to see how many
of those are, so from time to time. I’m using it and writing Cassandra or
ScyllaDB to see if someone exposes database, always there is someone if you use Mongo
or something it’s been well known that that Mongo was
a target of an attack that people connect and encrypt the data there and
ask for ransom and this is just because people expose the IP on the
internet usually without a need, so if you block the IP, of course you need to
use authentication, authorization all of that but just make sure you IP is not
public on the web, if you write in your company name here and there is a
result it’s sad but it’s something that you probably should
try from time to time. ScyllaDB Cloud security, this is some of the things that
we are using when we manage data for our customers, so we are using AWS key
management, we try to limit everything in VPCs, have a separate VPC
per cluster and all other measures but we have a session on that later today so
not going to spend too much time on it and. I’m going to conclude by going
back to the my first statement that security is never something that
you’ve really done with, unfortunately it’s like the laundry
you have to do every day, every few days you have to go back to it and test it
the best would be to automate the tool that test your security , do penetration testing or
make sure you are not exposed and go back to it to routinely otherwise
eventually we will forget something and you will expose yourself so whenever you
can minimize your expose, update your key from time to time use
two-factor authentication where you can for example ScyllaDB Cloud and very important
the last one apply available security feature so we
recommend updating the latest ScyllaDB version every time it’s go out and
that’s also true for the OS, so every day or every few days all kinds of
security vulnerability are published, the bad guys are reading that and just try
to use that to tackle kinds of system so keep your OS up to date, and the same
go for ScyllaDB and every other third party that you are using
