Refused access to make changes directly to the live site

Question

As a junior developer, I have been working on a project for 4 months. My project has been configured via the version control system TFS, whereas my teammate's project is configured by SVN. The project is on maintenance, so no regular work happens there. However, when our client sends a change request, it's most of the time myself who does the change, after unit testing and checking in the source code to TFS. It's again my responsibility to send those changes to my teammate, who is senior to me, who will peer review it, and deploy the code to production.

I asked my senior to hand over the FTP access for the production site to me, so whenever a change is required, I will release it to PROD under the following conditions:

1. If he is busy with other projects
2. Is he is unavailable (bus factor) upon which I will do an emergency release.

He is reluctant in handing over the FTP access to me. Once I asked our lead, on this topic, but our team lead also remained silent.

My Questions:

1. What do I need to consider before requesting access to the prod site?

2. How do make a business case that I be granted access to PROD as a backup in case my colleague is suddenly unavailable in the interest of business continuity?

Answer 1

Don't take it personally or as an insult. It probably has nothing to do with your competence as a developer.

There are certain responsibilities that are reserved for managers, team leads, and seniors; the main responsibility being access to live/production systems. Giving access to a critical system to a junior dev is most likely against company policy and overall not good practice. It is a good idea to have your code go through a more senior dev just to double check the code and make sure nothing will break. The company reduces its chances of having bad code make it into production by limiting the amount of people who have the ability to deploy it.

Answer 2

You assume that the senior developer has the authority to grant you access to the production server.

In a lot of development environments, that's not true. I work with companies where none of the developers have any access to the back end of the production servers. Only the security team and the systems administration team have access to the servers at SSH level. Developers can use an automated deploy system to push changes to the production servers, but only after the security team has reviewed the proposed code changes and merged the appropriate branch into the production branch.

A golden rule in security, as Peter says, is, if you don't have access, you can never be blamed.

Answer 3

Just because (in practical terms) they can allow you this sort of access doesn't mean that they should. All BS aside: there's a reason why companies make a distinction between "junior" and "senior". As a junior developer, you are expected to make a lot of mistakes and oversights. None, from the senior person you're describing, your lead, and their bosses, and their bosses' bosses are going to risk being able to pay their mortgages in exchange for making you feel more secure in your position there.

With all due respect, any fool with FTP access can drop files on a server. It doesn't even take a technical user - just someone with a copy of Filezilla, a host name, user name, and password. Many a company has experienced outages due to junior developers itching to prove themselves. So they give you access to do a deployment "on record", but what's to stop you from trying to do "off the record" bug fixes -- things you may not know how to undo -- and making things go from bad to worse? Why should they trust you? It's only been four months, and it takes much longer than that to feel out a staff member's style of doing things. No one's really got time to explain this to you, which is why you haven't received a response.

At this point, take a chill pill. Do the best you can at the duties you're assigned. Shine with what you have already. A year or so from now, you'll see more junior developers coming through the door behind you; and if you've paid attention well on the job in the cases where sh-- hits the fan and people are looking to keep negative attention away from them, you'll understand this paradigm much, much better.

Answer 4

As someone who works in IT Security profession, there are very good reasons that explains the behavior of your senior. The 2 most relevant concepts are

• Segregation of Duties (SOD)
• Least Privilege

Segregation of Duties

The principal of SOD states that incompatible duties should be done by 2 or more individuals to minimize collusion and security vulnerabilities. Code development (what you currently do) and code release (What you want to do) are incompatible duties in most circumstances. A developer who had access to production could develop code, embed malicious code such as backdoors or logic bombs into legitimate code , and then release the code to production all while remaining undetected. Such activity is extremely risky to the business, and the loss of critical IT resources can be ill afforded by most companies. If the data being worked on is extremely sensitive, business survival could be in question.

Least Privilege

The principle of Least Privilege states that a user should only have the minimum privileges necessary to perform one's job duties and no more. This concept is also closely related to CIA triad of security. Following such practice minimizes the risk of a user abusing IT resources or gaining unuthorized admin / superuser powers over a system, where he or she can do basically anything he or she wanted, such as:

1. Destroy data - Violation of Integrity and potentially availability

2. Deny legitimate users access - Violation of Availability

3. Disclose data to unauthorized parties - Violation of Confidentiality

Your job as a junior developer is to write source code. It does not seem it includes releasing to PROD. Therefore, your senior is following security best practice by denying you the access.

How to make business Case to be made as a backup for emergency changes to PROD

Having said the above, there should be a backup person who can do live releases in the case your senior is unavailable. Business continuity is impacted if only 1 person can do a particular task, a risk important to most reasonable management. Before presenting your case however, you should check the logging systems used for auditing changes to the production environment. If you don't have this, or if you do but its not monitored, or monitored but without a incident response plan to respond to detection of unauthorized changes to production, then there are bigger problems at your company. If you can assure management that emergency change requests made by developers are securely logged so changes can be reviewed, and unauthorized changes traced back to the responsible individual, then your case of being granted access to PROD increases much more. In order for a audit log to be defined as secure, the following characteristics should be met:

1. Access to the log is kept to the minimum number of users who have the need to know its contents. - Confidentiality

2. Logs entries are locked upon being committed so subsequent changes cannot modify previously written log entries. - Integrity

3. A unique user ID is associated for each user who makes a change along with a timestamp to indicate when the change was made. - Nonrepudiation

To further shed some insight into what can happen when access rights are sloppy, take a look into happened with the OP in these two questions:

1. I made a possible mistake on a live project at work, how to handle this mess?

2. Written warning from employer for following manager's instruction to deploy bugfix directly to production

As you are still a junior developer, your senior may not have had enough trust in you given the risks of mistakes in live production environment. This should not be taken personally, as your experience will grow with the time spent at your company. It should also be somewhat comforting for you to know that without access, if something were to go wrong, you would not be suspect, given you never could have accessed production, even if you wanted to.

Answer 5

It may be regulations.

In my job as a developer it's expressly forbidden for me to have access to production environments. This is a security measure. The ones making the software should not be the people putting it in production because then there's a chance for conflict of interests.

Answer 6

Normally the one with access is the one responsible if things go wrong.

Ideally, because the senior approves the changes and deploys them, he will be blamed if there are problems.

Now he can try to give you access, but that wouldn't shift the blame away from him. Instead he'd allow you to do whatever you want, and if you screw up it's still his fault.

That should explain why he doesn't want to give you access.

Answer 7

What do I need to consider before requesting access to the prod site?

The main thing you need to consider is a risk that the more you push for access, the greater the worry that you are too keen on getting it and would overuse or abuse it in some way. Could you really be trusted to use the direct access only in emergencies, or might you start bypassing the normal checks unnecessarily?

How do make a business case that I be granted access to PROD as a backup in case my colleague is suddenly unavailable in the interest of business continuity?

You do need to know what to do if your colleague is suddenly unavailable and changes to the server are needed. If you don't know, you should ask about it now, not wait until the situation arises.

Giving you direct access is only one of the possible answers, and not a particularly likely one. For example, there may be one or more alternates, who are not involved in the normal flow but who could do an update if needed. Or maybe the changes can wait for your colleague, or a replacement.

If you try to turn it into a business case for direct access that may get in the way of solving the real problem of not knowing what to do in that situation.

Answer 8

There is no way in hell you would be allowed to update a life website in any place that I ever worked in. And there's no way I would ever to that myself. It's the job of QA to check that your work is Ok and possibly their job to deploy. What you are asking for is totally out of the question.

Answer 9

I think you need to dig deeper into your reasoning and figure-out how this benefits the client. Have your boss clarify that it is all right to delay applying updates. Maybe the clients understand this or the nature of their business is not quite so time sensitive. Make sure your boss understands the risks.

Worse-case-scenario, client is expecting/desperately needs the fix. Are you suppose to tell them it is not going to happen because your boss is unavailable? If not, what lie does he suggest.

Someone in the company should suffer the consequences and I don't think it should be you, but you'll be the bearer of bad news.