security does not mean or necessitate over-restrictive control, rather
it is about understanding basic principles, following secure and safe
practices
That is a reasonably true statement, especially when you're describing a development environment. But be aware that the security/administrator's definition of "restrictive" is going to differ from the developer's definition!
the Linux kernel firewall matters
On an intranet Development environment, not so much. Such systems often require loose and flexible port access. In any environment, maintenance of local firewall rules across any number of machines is daunting (read: breaks functionality early and often, ties the administrator down loosening it).
the intranet's firewall matters even more
Absolutely. With a development environment, it often needs to be loose and open internally, so the border has to be more restrictive - definitely inbound, but also outbound.
remote root access should not be allowed, rather use of ssh key authentication
There are couple of best practices in this area which, combined, equal what you're talking about.
- Direct remote root login is discouraged due to attribution issues. Users, even administrators, should log in as themselves and
su or sudo to root so that their actions can be attributed to a person, not a crowd of people with the credentials necessary to log in as root.
- Remote root logins, if allowed (perhaps for configuration management software) should require SSH keys to make brute-forcing them impractical.
Are the above and the following questions the appropriate points to
discuss and ask, when it comes to security and safety inside a large
intranet?
They are all good points. However, you've missed the two most important parts of this adventure:
- Patching. Patching should be automated, centralized, and vigorously
often.
- Configuration management. Something like Puppet should be used to centrally manage the configuration of the machines and common software.
Patching is pretty obvious. Configuration management, while less obvious, is just as important. Configuration management means:
- When you need to tweak configuration, it happens across all your
systems without relying upon you to run around doing it everywhere.
- Developers who tweak their configuration (often with security
implications) are swiftly overridden and brought back into
compliance.
- When you bring a new system online, it's quickly brought into
compliance with your standards, and doesn't get "missed" or left out.
Is it a necessity or best practice to restrict a Linux user from
having "sudo" rights in his "own" system, for the sake of security and
safety, for protecting from outside threats?
There must be balance between security and business need. Developers often have a legitimate need for privileged access. To balance that need, security will often restrict privileges (e.g., sudo to particular commands but not a root shell), log for audit (e.g., bash to syslog, available in 4.1+), and limit damage to the pool (e.g., restrictive outbound access through the firewall).
Can security and protection from outside threats be performed with a
good set of rules for iptables and adequate maintenance of the
intranet's firewall?
No, more than that is needed, as described above.
To quote Gary Larson:
Is remote root access to a Linux machine, from inside the intranet, a
safe practice?
It is more unsafe than local root access, simply because the authentication of the user responsible for running commands is lost (or, removed 1+ steps). Requiring that privileged commands be tied back to a user, and logged that way, is necessary both in content (now you know) and consequence (developers held personally accountable are less inclined to do things they shouldn't).
