Ownership of SQL Server Files, Register Entries & Executables
Please see Security SQL Server on MSDN for a great resource on how to properly secure SQL Server.
Security is a very large topic, and needs a lot of thought to be done well.  The page linked above contains a large amount of resources from Microsoft about this topic.
From the above page, this is just a sample of topics:

Physical Security
Best practices for physical security strictly limit access to the physical server and hardware components. For example, use locked rooms with restricted access for the database server hardware and networking devices. In addition, limit access to backup media by storing it at a secure offsite location.
Implementing physical network security starts with keeping unauthorized users off the network. The following table contains more information about networking security information.
Operating System Security
Operating system service packs and upgrades include important security enhancements. Apply all updates and upgrades to the operating system after you test them with the database applications.
Firewalls also provide effective ways to implement security. Logically, a firewall is a separator or restrictor of network traffic, which can be configured to enforce your organization's data security policy.
Principals and Database Object Security
Principals are the individuals, groups, and processes granted access to SQL Server. “Securables” are the server, database, and objects the database contains. Each has a set of permissions that can be configured to help reduce the SQL Server surface area.

Database files, including data and log files, as well as backup files, should be owned by the SQL Server Service Account, or in the very least that account should have full control over them.  See this MSDN page for more details about that, including for SQL Server executables, and the Registry.