 Welcome to all about PostgresQL security. I'm joined by our speaker, Ibar Ahmed, Senior Software Architect at Prokona, who will discuss all of the available security techniques used in Postgres 13. My name is Lindsay Hooper. I'm one of the Postgres Conference organizers, and I'll be your moderator for this webinar. If you need anything, you can message me in the chat function under Postgres Conference Host. A little bit about your speaker. Prior to coming to open source development, Ibar had fast experience in software design and development, where his main focus was on the system level embedded development. In 2006, he joined EnterpriseDB to start his career in open source, and he has contributed to the PostgresQL community as well as other open source communities. His contributions range from the main performance feature enhancements to various PostgresQL modules. Within the database field, he has experience in other well-known databases, such as MySQL, Oracle, and NoSQL databases, such as MongoDB and Hadoop. His experience is not limited to core databases, but rather with the tools related to databases, such as Hive, HBase, and Spark. With that, I'll hand it off to Ibar. Take it away. Hello, everybody. So good morning, good afternoon. So in which world are you living? So today's, we are welcome to you, the PostgresQL world. So today's topic is all about PostgresQL security. My name is Ibra Ahmad. Hey, who am I? So as I think she already introduced me, that my name is Ibra Ahmad, and I have been in software industry since 1998. I have been contributing in different open source software like Chromium, Chrome, and PostgresQL. So I have more than 14 years of experience in PostgresQL development. So I am, I authored two books in PostgresQL, PostgresQL Dwellers Guide, and PostgresQL 9.6 High Performance. I also contributed in for the PG upgrade, index only scan, and on foreign data wrappers. I'm also a PhD scholar. And so today's agenda, so initially we will discuss what is database security? Because it's really important to discuss that what is security is and what a database security means. So then we will discuss a triple A and what is triple A? Authentication, authorization, and accounting. So we will discuss each topic in detail. And then we will discuss some key concept of encryption. And then we will discuss the security best practices. At the end, I will entertain your questions and give you the answer at the end of the slide. So database security. So database security comprised of five different things, five different things. The first one is the network. So where your database is or your node is, you have to take care of your security measures. Where is your node in the network? Because you have to secure your database, your node, everything from the out incoming traffic from the network. So you have to secure your node from the network from where it can be accessed. So it's the first thing. Then you have to secure your host. First you'll secure your network, then you have to secure your host in which your database is running. So first you have to secure your network, then you have to secure your host, then you have to secure your database. So after that, you have to secure your application. And at the end, you have to secure your data within the database. So if we think that if one of these module is compromised, then there is no meaning of security. That's me, if your database is not secure and how much security you are providing is meaningless because it's already compromised. So you have to secure all of these things, your network, your host, your data, your application and your database. And each layer you have to secure database separately. There are different tool available to secure your network and there are different tools available to secure your host. And similarly, there are many configuration available to secure your database. And when you are writing your application, you have to secure your application. And last, you have to secure your data within your database. In this webinar, we will discuss how to secure your data and your database. In this webinar, we will not discuss how to secure your network, how to secure your host and how to secure your application. So we only discuss how to secure your database along with your data. So in this picture, if you see in the middle, you can see a user, you give the access him to the database, to the network, to the host, to the data and the application. And the man in the red, you only give access to the application. So you have secured your database, network, host data from that man. So that man cannot access all of these four module. He can only access the application. So you have to define some rule. So what kind of a user can, what kind of a level of security. So a triple A, that's the most important thing. What is the triple A? Triple A is authentication, authorization and accounting. Very simple words when we are talking about this authentication. That means who are you? Or which user are allowed to access the database? So you have to authenticate that these user can access database and these user cannot access the database or the user accept these user cannot access the database. So authentication means to authenticate the users. It's a similar when you are logging to the Gmail account, you are logging to the, so that user that when you're providing your user name that if you are allowed then the system authenticate you that you are the valid user. You can access the system, you can access to your Gmail account. Similarly in database, if you have a user and database allow them that and this allow you that's called authentication. So this whole module where your user is being authenticated is called authentication. So then the second is authorization. What is the authorization? So when you are able to authenticate your user, then the system has to decide that what you can do with the database. We're talking about the database term that after the authentication, what things you can perform to the database is called authorization. So database give you some privilege that you can do this and you can do this and you cannot do these things. So this is authorization. So in simple words, what are the user allow to access is called authorization. And the third one is accounting. So what the user did in the database, the third one is what user did to the database is recorded somewhere and that's called is accounting or sometime we are calling it auditing that we see the audit logs that what things our user has performed. So with these things, with these triple is the main security expect has been covered. So you are authenticated that you are allowed to enter into database or not. You are authorized to do this task or not. And all your action has been recorded and call accounting. So within the database, your security is complete almost. Almost that's I will discuss that where you have to do some more security measure. So the first one is the authentication. So be careful when I'm talking about the authentication, authorization and accounting or in sense accounting or auditing, I will talk about in terms of post-credits. So there are some more things than we can discuss which are not related to post-credits but we are not discussing that. So whatever I will discuss here is related to post-credits. So now when I'm talking to the authentication, the post-credits has three kind of authentications. So on the right side, you can see the operating systems. Right, I just put some main operating system like Windows, Linux, Maxwell, Mac OS, FreeBSD, you can put there. So the right side is totally covered with the operating systems. And in the bottom, you can see the users. And on the left side, as you can see, external tools, external tool like Radius, LDAP and other tools. So in the middle, you can see a post-credital mode. So we have three kind of an authentication method in post-credits as well. First one, post-credits has its own authentication method. So I am calling it a post-credits to an internal authentication method. And post-credits can authenticate you from using the OS authentication. Similarly, post-credits has also has a capability to authenticate you from the third party tools, a third party servers. So these are the three things. So if we are discussing post-credits, internal authentication, there are a trust, reject, MD5, scram, and cert. So for the first, which is calling the trust, that's mean when you put trust into your configuration file, that mean that user does IP address of this database is allowed to enter that database. So don't think about, don't ever think about use trust in your production database. So just think about that there is no authentication method trust in your production database. So it's totally out of question to use that as far as the security is concerned. If you don't want any security and you just doing that some practice and something that you can use that. But if you are doing that in a production and have your secure database, don't use trust. So I will tell you how to use that this trust, reject, MD5, scram, and cert. So what is the MD5? MD5 is the hash and MD5 hash it will use. So if you have very small number of users and you want to store that users and then you can authenticate user using the MD5. That's really good for the very small number of user. And again, if you want to use the scram, it is a better than MD5 because has a better encryption. So you can use scram and for the certificate based authentication, you can use the cert. That's another way to authenticate your user. And if you want your Post-Rescueal if you don't want your Post-Rescueal to authenticate you, then you have an OS authentication model. That you can do that PAM, peer and IDENT. So you can use either of these to authenticate using the OS authentication. So then you have an external authentication method. And in that case, you have JSSIPI and SSPI and LDAP and the radius. So if you have a large number of users and you want to authenticate that user, a large number of user and you want to authenticate user and you want to have on a central system where you want your user to be authenticated, then LDAP is one of the best method to use that. So if you have a large number of users and you want to authenticate from a central location then use LDAP. So radius is not a very much recommended way to authenticate your user external. So you have these method in Post-Rescueal to authenticate. So that's the authentication methods. So I just told you that these were the authentication method you can use that. How you can use that? Where you can put these values to be used? So Post-Rescueal have a file which is called pghba.com. I think who are familiar with Post-Rescueal, they know Post-Rescueal has a data directory which is called a pgdata. So it's environment variable, the other pgdata. So in which you have all your cluster files, your database files, your configuration files, every file except some table spaces. I'm not talking about that. So your configuration files and your data files are reside into the pgdata. So do the pghba.com file. So you have a pghba.com file. So pghba.com file provides authentication for a user based on the IP address, based on the databases. So there are three things that you can provide that this IP is using this kind of an authentication method or this user is using this kind of an authentication method or this database is being authenticated using this authentication method. So if you just see the pghba.com file that the first column you can see is our local. So then the database name, then the user name and then the authentication method and then if you have some authentication option which is dependent on the authentication method, if you have authentication option, then you can also put that authentication method. So instead of local, you can put the host name. Sorry, the host. When you put the host, that means you have you are providing the database name, you are providing the user and you are providing the address. And this is the can be the IP address. So that's mean if you're providing the host, that means host a host and then you are providing the name of database and then you are providing the user name and then this IP address will use this authentication method. So similarly, a user is coming using SSL. So this host SSL will be used on if database name is which you provide in the database and the user name providing the user and the IP address you are providing in the IP and then this authentication method will be used. So that's all the option is there. So for the example, in the host, I just put host and then all, all mean the all databases because I already told you the second column is the databases that all mean the all database. That mean a host is coming with any database. It doesn't matter which database it's trying to connect a user, any user is coming and IP address that mean if any user of connecting with any database coming from local machine, which is 127.0.0.1 is trusted. That mean there is no need to authenticate it's already authenticated, it's a trusted user. So that mean if you are running on database and you have this line on your computer then you can connect your database without providing anything that you will be connected. You are a trusted user because you are on the same computer in which database is running. So it's, so the second line, if you see, just skip the second line because it's IPv6. So I'm not talking about IPv6 right now. So if you see in the third line that you can see the host then a replication database with PostgreSQL user is coming from the same computer then it will use the MD5 authentication method. It's just an example, you can write any valid values here. So a user PostgreSQL coming to connect replication user from the local IP address then MD5 authentication method will be used. So here 127, you can write IP addresses. You can write the network addresses where you can provide the IP mask so that these ranges of IP address will be use this authentication method. So you are good. In this case you are good to have an access list. I already called it an access list. A user access list. So that's mean, whichever you, so you are denying everything. I already told you don't use trust in your production database. So you are not adding anything in trust. So you will provide the IP addresses here and you can provide the username and you can provide the databases and you are using SSL or not. So you can control who can connect your database. You can connect which IP address can connect to your database. You can control which user can connect to your database. You can connect with database use which authentication method. So you can control your, all the authentication using a one single file which is our HPA.conf file. It will not provide the username password combination for you but it will control its access list so you are providing who can access the database. So you are allowing or rejecting the IP address, the database is our user based on this file, basis of this file. So that's very key file for the security of Postgres care. So you have to be very, very careful when specifying anything in that file. So you have to be really, very, very careful. So don't put static dot static dot a static, a zero, a small static, a static like, don't try to put all an IP address in a database in a user or 0.0.0.0. That's mean all the IP address can access database and don't try to use the trust. So it's up to you, you can write anything but you have to be really, really careful when writing something in that file. So authentication is over. That's when I'm not talking about each and every authentication method here. So I am planning to have a separate webinar on authentication method and then authorization then accounting are separate. So in this webinar, I'll try to cover all of these in general and then we will go in detail to configure Postgres SQL to using LDAP to configure Postgres SQL using JSSS API and configure Postgres SQL with different methods. So we will do that in later webinars. So in this, I will try to cover the main and generic idea of security analysis. So next is authorization. So in authorization, we have role, user and groups. It's called when you are controlling that usually controlled by using, you are creating the user, you are creating the groups, you are creating the roles. So it's a general term and you are creating and how you are controlling thing in the normal world, you are controlling that this is allowed and this is disallowed. So normally in a database world, we call it a grant or revoke that you can grant a user something that a user can do and you can revoke the capabilities of the user. Then and grant a revoke, you can, you are doing that on object. So usually you are doing grant and revoke on the object like a table, like some other object. So, but Postgres SQL have some other concept which is a role-level security. You are not allowing or disallowing the whole table. So you giving the permission of your user to access some roles. So you are not disallowing user to use, do not use the whole table. You can allow him to use a portion of the table. That's called a role-level security. So in authorization, what is the grant at revoke? So grant. So here I have an example. So I don't want to write some text here. So just here is an example. Write create table accounts then into some manager table and a company name and a company email address. So I just inserted a row in that type manager. I just put that the EMT, then I put a parcona in that and then I put that the, sorry, it's just typo here. It's not EMT, just sorry about that. It's managers, it's managers instead of this EMT. I will put it in the slides if you need that. So it's just from another example. So I just, what I did, I just log in using the manager's database. So I just did a select static from accounts. So permission denied for table accounts. It's just the permission denied because that table has been created using a post-rescue user, a different user. I created table using a different user. So this is not allowed to access that. Then a piece equal then again, I connected using a normal post-rescue or a regular user. Then I grant command, I use a grant command like grant all own accounts to managers. So I gave the access to the account table to managers. Previously when I have created a table using a Wegrant, a different user and then I log into the manager's user and then try to access that table to access denied because that table is not belong to that user. So now I grant that the access and grant all mean I am giving the full access on accounts table to managers user. So now manager user can fully access the accounts table. So like piece equal, post-rescue minus you that mean I'm logging using the manager's user and now select static from accounts will work here. So now on the right side, I have our revoked example. So in this example, I am logging using my Wegrant or post-rescue user. So now right now it's a Wegrant user because I'm using the Wegrant user. So revoke delete on accounts because that user belong to the Wegrant user. So I am revoking the delete privileges. Previously I provided all the, I am granting all the permission to manager's user on the table accounts. Now I am revoking a delete permission own accounts table from a manager's accounts table. To the, from the manager's user. So now after this statement, manager's user cannot delete any row from that table. So again, previously I granted all the privileges to the manager's user and then manager's user can do anything to the accounts table. In the next, on the right side, I am revoking a delete permission from the accounts table from the manager's user. So when I use, I am logging using the manager's account, manager's user, then delete from accounts will give you the error permission denied for the accounts. So that's really simple. Previously I provided a grant access and now I am revoking the delete permission and it works. That's called a grant review. So what I told you previously, what is the authorization? Authorization means what a user can do or what a user cannot do. That's authorization. So what thing a user can do a basic thing. That's authorization. What thing a user is authorized to do. So here on the left side, on the manager's table is authorized to fully access the accounts table. But on the right side, manager's user can do everything on accounts table except delete because we just revoked the delete permission to accounts table from the manager's user. So I told you, when you are using the grant and revoked and we were dealing with the objects, that we completely drop the idea of deleting, idea of deleting all the rows from the table. Like we have an idea that we have a revoke, we can revoke the complete select statement from a user. But there are some use cases, you don't want this. You don't want to revoke the privileges like delete privileges or select privileges from a user from a whole table. Because there are some cases where you want to give access to a user for some portion of your table. Some rows of your table or one row of your table. One row of the table, that's our row level story. So instead of object, we are now talking about the rows, the data, our separate rows data. So like you can grant or you can revoke some permission to the some rows of the data from particular user. How you can achieve that? So here, ktable accounts I have just created a table. Then I am allowing row level security own table accounts. So I just alter that table, alter table accounts, enable row level security, that's a very important line. So alter table accounts enable row level security. Now row level security is on. So now I am creating a policy, create policy, accounts manager, its name of the policy, it's just name of this, it doesn't matter what name you are providing here. Own, that's the table name. To manager, using manager is equal to current user. First one, create policy, account manager is the name of the policy. Own mean name of the table. To mean that column and the manager are two managers, if it's a user to manager, user and the two, using manager is a column name and then current user. That means if current user is equal to manager, then this will, you can only access the that host. That means if you have a data managers and you are login with the managers table, then you can access that row. So if you have a row which have a column manager EMT, then only EMT user can access that row. So again, see here, I have created a table accounts and have a column manager and a text. Then alter table accounts enable row level security. I have created a row level security on that and I have created a policy that the manager column is equal to current user, then we can access the row. So I just grant all accounts to manager because otherwise you cannot access that table. Insert into values managers per corner fooexample.com, then EMT per corner fooexample.com, that's the media tab. I just select static from accounts because this table is belong to the complete. So I'm just selecting the whole table here. On the right side, I just log in using the managers user. And when I issue a command select static from accounts, you can see only the row which have a column manager named managers appears because we log in using managers and manager column have a managers row, row where manager value. So it's compared a current user, it's compared the current value of the user, it's compared the current user with the value in the table column manager. If this match, it will show you the result. So if you log in using EMT user, like if you see on the right side, pc equal post-crescule minus u, e and t, not managers, then when you issue a command select static from accounts, it will show you the EMT per corner fooexample.com, only. It will not show you both the rows. So that's very interesting because we deny the excess and we are not giving the error, but people cannot see that rows. People can see only the rows which has for them. So it's just a trick. We just created a policy on that. So only that use the column manager have that the same username and that rows can be accessible to that user, not all the rows, but that is called a row level security. So I just briefly discuss what is the authorization. Now we're coming to the accounting. So sometimes database terms, we are usually used auditing. So audit, so, and, but in triple A term, we are usually called as accounting, but in database term, we are usually used the auditing. So there are three kinds of logging. The people are mostly interested. The first one is a network log. Second one is a database log. Third one is our application log. That means whenever you want to see how many IP address and which IP address we're doing what thing that is called a network logging. So you can see on your network log that this IP address access database one million time or 10 times or five times or at which time this IP address is accessing database and how long, so that's called a network log. So you can see in the network log that this information is, and this IP address is accessing the database. So then it comes to the database log. Database logs mean how databases use that you are inserting a data into table. A user is deleting a data from the table. A user is selecting data from the table. A user is selecting or performing some action on the database of which action is usually performing on the database. So usually we'll use a database log to monitor these kind of activities. Then comes to the application log. It's all dependent on the user, which kind of a log the user wants that it's totally dependent on the application. So we are not talking about the application log. We will briefly touch on that for club. We'll touch that. At least we know the IP address, but then we are main concern about in the security is a database logging because we are discussing the post. Not the whole security module. So there are, I'm just thinking there are many, many tools available. Many, many. I have, I'm last working on a monitoring tool. So I think dozen of tools which are available for PostgreSQL for the auditing or the monitoring. So PostgreSQL, when they have a login system. So PostgreSQL have a PG stack statement. It's a view in which you can see the statements level log in, which statement is taking what, how much time and what is the, which user is doing and which database is accessing how much time. And so you can query that table and you can get a full information. So a log statement where you said that log statement is equal to static that mean also log all the statements. So you can configure PostgreSQL logging system. So it's quite a, PostgreSQL provide really good logging system here. So you can even log the point PD stack activity where you can see the activity on the database. So it's PostgreSQL logging system really good to do that. But along with that, there are third party tools are available. So like there are some basic tools are available. PG audit is one of them. And PG stack monitor. Actually I built that and Prakona is sponsoring that tool that it gives a really good real time aggregate of aggregation and everything and the monitoring the PostgreSQL system. So you can monitor your PostgreSQL, you audit your, you can use for the accounting auditing for your database is really good to sponsor so you can. So I have link of PG audit, PG stack monitor and audit trigger. So there are a dozen of you see, I can provide here. I told you that I think dozens of tools available for that. So then we have a, you can write your own trigger based custom implementation. Like you can write a trigger on a some specific user that that whenever that table is assessed, then you can audit that statement into another table into the file into something. So you can write your own triggers to do the accounting. So it's a custom implementation. It's a user base, how much you want and how much you want. The next topic is the encryption. Suppose in encryption, there can be a three level encryption and all the three levels are really important. The first one is encryption at rest. That mean where your database reside, where you have your database that is that is encrypted. The second one is application level encryption. So that application level, then your application is do the encryption for you. Third, encryption in project that on a network, the data is encrypted that nobody can capture your data in between. So you have to take care of all of these. And encryption at rest, file system encryption, you can do that. So for the file system of encryption, we, I will say how many, I think many methods are available. You can see, you can Google it, and you can see the file system encryption available for different, for Linux, Windows, and other operating system you can see. So you can encrypt your system and you can have your database on that encrypted file system. Postcase will only provide a column level encryption. It's, I'm just calling it's a column and encryption. So you can encrypt your data. It's a country module in PostgreSQL where it's called PG Crypto. And then comes a database, a table level encryptions come and in a table level encryption, PostgreSQL does not have a table level encryption or it's called a DD transparent data encryption. So it's doesn't have, but PostgreSQL community is working on that to have that in a new future. So I have provided a link where these things are being discussed. So I just put that no discussion is going on and implement that in PostgreSQL, but it's not there. And encryption in project, PostgreSQL provide the SSL. So you can convert to figure SSL. So you can connect your client using the SSL. So that can be possible in PostgreSQL. So file system, this encryption, you have loop back device. You can use that and you can encrypt in the Linux. So geom-based disk encryption or GBDE in free ABSD it has as a DM Crip. So for using this, you can have a file system disk encryption. So you can encrypt that and you can use a PostgreSQL on that. So your data will be secured at rest. So no, because we are not discussing, I'm not discussing the, how do you encrypt your data on the disk because it's not topic of PostgreSQL. But when we are talking about the PG Crypto, that is a PostgreSQL thing. So we want, we have to discuss that in this webinar. So here I have created a table, create table, foo. So where we have a name and we have a data. And we want to encrypt that data. So I just insert the data, insert into foo, values, foo, PG, same encrypt, that's a function of then a bar bar is a data. The bar is a data, I'm just inserting that data and I'm using some textual key. I'm just putting an AAS key. It's not a key, it's just using a text. So it encrypt using that. So select static from foo. You can see, you cannot see the actual value, which is a bar or just an encrypted value you can see here. But you have, if you have the name of the key, that AAS key, then you can decrypt that data using PGP, same decrypt. And if you provide that key, then you can see the data bar, you can see the data bar. So if you don't want to encrypt and decrypt your data, if you want to use a table where you want to store your password and you don't want to decrypt that, then I've used create table. A table is already created because we just created that insert into foo values one foo CRIP. In that case, I'm using a function named CRIP and then my pass is my password and then I use a salt here. Then the row is inserted. Then I select static from foo, then this value is coming. This is the encrypted value of the password. So now I cannot decrypt that value, but how I can show that my password is correct or not. Then I put select static from foo where password is equal to then CRIP my pass password. I again encrypted that my pass and then I check that it is correct or not. If it's correct, then I am getting the row. If it's not correct, I'm not getting that row. So if this my pass is not correct, if I put here my pass one, so I will not get any row here. So that's the thing that if you are, you have encrypted your password and store that password and nobody can see that what is your password. Even if somebody knows your database password, cannot see what is your password in that table. But if you want to verify it, you can just put your password, what you know your password and you want to try that, it will show you the row, if it's password is correct, if it not shows you the row, if password is incorrect. So that's really good thing that nobody can decrypt your password even if have a super, even he is a super user of database, he cannot decrypt your password within the table. But you can verify that password if you have already know the password. So security best practices, it just tips four, five, six tips. Always use firewall to protect the attacks from the attacks because if you are not using the firewall, you will always be vulnerable to attacks. Don't give access to all, use private list of IPs to give database access. It can be used using firewall, so your host is secure. It can be used pghba.com to give only access to some IP addresses to access the database. Never expose your database port to internet. So if you have a system and your application, so your only your five, four, three, two port is open to your application, not for the whole world. So a whole world can see your five, four, three, four is open. So it should be only open for your application because people are using your application, not the database. But so don't allow direct blogging to the database system. If your system is on the internet and somewhere and then you have a database installed on your system, so don't give access SSH access directly to the database to all the internet or all the network. Secure your backups. If your backups are not secured, your data is not secure. If you're securing your database, you have very good security system for your database, but when you are taking a backup and it's just hiding somewhere and it's not secured. So database is not secure because the backups are real data, so you have to secure your backups too. And this is a very interesting thing. Listener access is static. In a PostgreSQL.conf file, be careful when you're doing, that means you are giving the access to this type, all IP addresses. So be careful about that. That's it. That's it from my side. So I think we have already spent, we have eight minutes for the questions and answers. Yeah, absolutely. Thank you so much, Ibar. Have to say between your presentation and all of our attendees, this is one of the most active chats we've probably ever had. So lots of good questions have come in. If we don't have a chance to get to it in the last few minutes, well, I'll send them over to Ibar, who could follow up with you specifically. So taking it from the top, is there a difference between local and host dot, dot, dot 127, dot, oh, dot, oh, dot one. And of course it's IPv6 equivalent. This comes from the PostgreSQL authentication configuration slide. Okay, let me go to that slide. Yeah, so sorry, can you please repeat the question? So I just missed. Sorry about that. I will start reading the question, sorry. Sorry, just repeat the question. Is there a difference between, quote, local and quote, host 127, dot, oh, dot, oh, dot one? Yeah, if you're the correct that this local name is a local machine. And if we are providing here, is the IP address is the same thing. It's a local host. In the network time, local host is equivalent to the 127, dot, zero, dot, zero, dot one. It's both the same thing. But we are, when we are talking, we are writing local here in pghba.com. On the first column, that means it's a local machine. We are explicitly specifying that, specifying that. So there is nothing need to be right here in the address. So if you, the similar equivalent of that, if you write it here, host, then database, then user, then put 127, dot, zero, dot, zero, dot one, then it's the same thing. So first line and second line is same if address is 127, dot, zero, dot, zero, dot one. That's it. It's funny, I'm getting a note that actually that conflicts with the crowdsourced answer. So I'll definitely send you this chat e-bar so you can check it out. Okay, for sure, definitely. Okay, another one. How does RDS PG SQL use pg underscore hba.com? Don't have an experience with the RDS. Sorry about that. Okay. I can clear one more thing here, the previous question. If people are, I think they're confused about the local and local host. When I'm calling as a local is, that means it's also a unit. If we are talking about the unit's domain socket, it's there because there is no concept of IP addresses here. So if we put local and then a database user and no, then it's unit's domain socket will be used and you will connect. But if you provide host all, all and this, it's same thing because you are connecting from the local host and because for the unit's domain socket, you are connecting from the local host. Then it's things are same, but how Postless SQL is creating is a different thing. For the user perspective, it's the same thing. Great. Another question. Is there an order of precedence in an event where multiple policies conflict? Can they conflict? I'm not very much sure about that. I will answer it in the chat room. When I see the chat room, I think the last one has a preference. And I think I will reconfirm that, I will reconfirm that and answer on that, okay? Wonderful. So next one, you mentioned earlier that you can use LDAP to authenticate a large number of users. I'm assuming we can combine LDAP users with row level security. Is that correct? Yes, you can use that because it's a similar user. If LDAP is used only for the authentication. So that's correct that you can use that user for the LDAP. That's correct. You can use that. Great. Any specific use case of multiple policies that conflict? I'd expect all policies to be and and only rows that successfully qualify for all policies are displayed or processed. Yes, all policies should be applicable because if the rows are accessible from all the policies, then you can access the rows. That's correct. Great. And our final question, I can't believe we're fitting all these in. Any thoughts on security of restoration from backup? Restoring a backup, actually there is no concept of because you have to do that in yourself. You have to provide your security for your backup and your restoration. Postgres doesn't provide anything for the restoration. You have to do that yourself. Okay, fantastic. Well, those were all of our questions and we are now at the top of the hour once again. So I will say goodbye for now. I hope to see everyone online at future webinars. Thank you so, so much, Ibar. This was a fantastic presentation and thank you to all of our attendees for this incredible chat. So whether it's morning, evening, afternoon, middle of the night, no matter where you are, I hope you have a great rest of your day and I will see you back here next week. Thank you, everybody.