Saphira Linux databaseDragon

When an application and its database run on the same Saphira machine, local access is usually the simplest design. There may be no reason to expose the database service to an external network at all. The application uses a local connection, and the database remains available only on that machine.

Remote access is for the cases where another host legitimately needs the database: an application server, a separate web server, an office service or another controlled machine. It should be an intentional relationship, not a reason to open a database port to the entire Internet.

A useful way to understand database access is as four connected questions: which user, which database, which privileges, and which source host? Together they determine what an application may do and where it may connect from. A user that can read one application database does not automatically need access to every database or the ability to change its structure.

• Create a dedicated application user rather than sharing an administrative account.
• Grant the privileges the application needs for its own database.
• Keep local-only users local when no remote connection is required.
• For remote access, name the actual approved source host or network.
• Review and remove obsolete users, hosts and privileges as applications change.

A remote database client may reach the server over IPv4, IPv6 or both. Treat this as an ordinary part of the design rather than assuming every remote connection is IPv4. The database's own user-and-host permission and the network firewall rule are related layers, but they are not the same thing: both need to match the access you intend to allow.