Microsoft SQL Server (MSSQL) is a powerful, enterprise-grade relational database management system (RDBMS) developed by Microsoft. Renowned for its scalability, performance, and tight integration with the Windows ecosystem, it’s a preferred choice for organizations that rely on .NET applications, Active Directory authentication, and centralized management. MSSQL uses Transact-SQL (T-SQL), Microsoft’s extension of SQL, to manage and manipulate data with precision and flexibility.
Powering thousands of corporate systems, financial platforms, and government databases, SQL Server delivers advanced features such as high availability, data encryption, and built-in security auditing. It’s designed to run efficiently across a range of Windows Server environments—from small business deployments to large-scale enterprise clusters—making it suitable for both production and lab setups.
In this guide, we’ll walk through how to secure and harden a fresh installation of Microsoft SQL Server 2022 on Windows Server, ensuring your database environment is properly configured, locked down, and ready for secure operation in any network environment.
Installing MSSQL Server
Download the Microsoft SQL Server 2025 Developer Edition installer directly from the official Microsoft SQL Server downloads page
. For this guide, we’ll be using the Developer Edition, which provides the full feature set of SQL Server Enterprise but is free for non-production use — perfect for building, testing, and learning in a secure lab environment.
Edition Breakdown — Which One Should You Use?
| Edition | Description | Feature Set | Licensing / Use Case | Ideal For |
|---|---|---|---|---|
| Developer | Full-featured edition for learning, testing, and development. | Identical to Enterprise — includes advanced features such as Always On, Transparent Data Encryption (TDE), and performance tuning tools. | Free to use but not licensed for production workloads. | Labs, training environments, proof-of-concept systems. |
| Express | Lightweight, free edition with storage and resource limits. | Core database engine only — no SQL Agent or advanced Enterprise features. | Free and redistributable for small-scale applications. | Small web apps, lightweight APIs, or learning basic SQL concepts. |
| Standard / Enterprise (Full) | Commercial production editions designed for business-critical environments. | Includes advanced security, scalability, clustering, and management features. | Requires paid licensing based on cores or CALs (Client Access Licenses). | Enterprise production servers, corporate networks, and large-scale systems. |
Recommendation: For lab and learning environments, choose the SQL Server Developer Edition. It provides the full Enterprise feature set at no cost, making it ideal for testing, security demonstrations, and training exercises.
Start the installer and select “Custom” select all the defaults in the next
Choosing a Secure Installation Location
By default, the SQL Server installer suggests creating the setup media on the C:\ drive, such as C:\SQL2022. While this works technically, it’s not the most secure option because the root of the C drive often has broad NTFS permissions that grant read and execute access to all local users. This can allow unauthorized users to browse or copy installer files, view logs, or tamper with leftover setup media — increasing the risk of information disclosure or privilege escalation.
To follow best practices, I created a dedicated and secured directory on a secondary drive: E:\Installers
This location is used exclusively for software installation files and is protected with restricted permissions so that only Administrators and the SYSTEM account have access. This reduces the risk of sensitive setup files being exposed or modified after installation.
Why This Is More Secure
| Risk on C:\ | Security Benefit of E:\Installers |
|---|---|
| The C drive root often allows read access for all local users. | E:\Installers can have custom NTFS permissions, restricted to Administrators and SYSTEM only. |
| Setup logs, temporary files, and configuration data may reveal service account details. | Restricted access ensures sensitive installation data and credentials remain protected. |
| Leftover installation media can be tampered with or replaced by standard users. | An isolated drive and locked-down folder preserve the integrity of installation files and prevent tampering. |
Click “Install” to complete the install.
Now the Wizard displays select “Installation” then “New SQL Server standalone …“.
Choose “Developer” edition.
When the setup wizard reaches the “Install Rules” stage, you may see a warning for Windows Firewall. This alert simply indicates that SQL Server’s default network ports (such as TCP 1433 and UDP 1434) are currently blocked. This is completely expected and actually desirable during a secure installation.
Because this configuration is intended for a hardened, security-first environment, we will not open any SQL ports for remote access. The server will remain locked down so that only local system processes or authorized management tools can communicate with SQL Server.
If remote connectivity is required later, it can be enabled safely by creating targeted inbound firewall rules for specific IP ranges or application servers—never by opening the ports globally. Keeping these ports closed by default follows best practice for minimizing attack surface and aligns with the ACSC Essential Eight principles.
Untick “Azure Extension for SQL Server” and click “Next“.
Select “Database Engine Services” only. We’ll keep this installation minimal to reduce the attack surface and maintain a clean, hardened environment. If additional components are required in the future, they can be safely added later using the SQL Server Setup wizard without reinstalling the entire instance.
Next, assign a name to your SQL Server instance. In this example, we’ll call it “DBSRV2“. This name will later be used in connection strings by your applications to identify the database server. Avoid using spaces or special characters in the instance name to ensure compatibility and prevent connection issues.
Leave defaults and click “Next“.
Leave Windows Authentication Mode selected, then click “Add Current User” to grant administrative access to the currently logged-in domain account. While you could assign a security group here, we’ll follow the principle of least privilege by limiting access to the single domain user performing the installation. Additional administrators or groups can always be added later through SQL Server Management Studio (SSMS) if required.
Best Practice: Use a Custom Drive for SQL Server Data
If your system has more than one drive, it’s best not to install SQL data and logs on C:\.
Keep only the SQL program files on C:\ (the binaries), and store databases, logs, and backups on a separate drive such as D:\ or E:\.
⚙️ Recommended Data Directory Configuration
| Field | Recommended Path | Description |
|---|---|---|
| Data root directory | E:\SQL | Defines the base path for SQL Server data files. Keep it simple and separate from the OS drive for better isolation and performance. |
| System database directory | E:\SQL\Data | Stores system databases such as master, model, msdb, and tempdb. Moving these off C:\ improves both security and disk I/O efficiency. |
| User database directory | E:\SQL\Data | Default location for user-created databases (.mdf files). Keeps all data in one secure location. |
| User database log directory | E:\SQL\Logs | Stores transaction logs (.ldf files). Separating logs from data improves recovery reliability and performance. |
| Backup directory | E:\SQL\Backups | Stores database backups (.bak files). Makes it easier to secure, encrypt, and manage offsite backup copies. |
Click “Install” to complete the installation.
Click “Close” When compete.
When we installed MySQL, we used phpMyAdmin as our management interface. For Microsoft SQL Server, the equivalent tool is SQL Server Management Studio (SSMS). Because we configured a secure installation and did not open any network ports, SSMS must also be installed on the same server where SQL Server is running. This allows you to manage the database instance locally without exposing it to external network access.
You can now log in to your Microsoft SQL Server instance. Since this is a default installation and we haven’t yet configured an SSL certificate, select “Encrypt connection: Optional” when connecting. In a later post, we’ll configure a trusted certificate to enforce full encryption for all SQL connections.
Summary
Installing Microsoft SQL Server securely on Windows Server requires more than just running the setup — it’s about minimizing attack surface, controlling access, and ensuring encryption and isolation from the start.
In this guide, we:
- Downloaded the Microsoft SQL Server 2025 Developer Edition directly from Microsoft for a secure, feature-complete lab build.
- Chose the Custom installation path to maintain full control over installed components.
- Selected only Database Engine Services to keep the setup minimal and reduce unnecessary services.
- Used a dedicated folder structure on E:\SQL for data, logs, backups, and temp files — improving both performance and isolation from the OS.
- Left Windows Authentication Mode enabled and added only the current domain user, following the principle of least privilege.
- Configured SQL to use local-only access, keeping all network ports closed to prevent remote attack vectors.
- Deferred certificate-based encryption for now, connecting with “Encrypt connection: Optional” until SSL/TLS is configured in a future step.
- Prepared a post-install PowerShell hardening script to lock down NTFS permissions for Administrators, SYSTEM, and the SQL Server service account only.
- Ensured compatibility with AppLocker policies by separating binaries (C:) from data (E:).
By following these steps, you’ve created a secure, isolated SQL Server installation that adheres to enterprise security principles like least privilege, data separation, and defense in depth.
✅ Key takeaway: A secure SQL installation starts with limiting exposure — install only what you need, isolate data, restrict access, and harden permissions after setup. Every decision reduces your attack surface and strengthens the overall integrity of your environment.
Post-Install and Other Tutorials
Now that Microsoft SQL Server is installed and hardened, the next step is to perform post-installation security tasks — such as enabling SSL/TLS encryption, scheduling regular database backups, and applying least-privilege permissions for application and service accounts.
Post-Install Security Checks: Verifying Open Ports and Vulnerabilities