Assigment Week 8 – BD308 – Hilma Aulia – 2581494366

Nama : Hilma Aulia Daffa
NIM : 2581494366

Pertanyaan:

  1. Why is MFA significantly more secure than a password alone?
  2. Explain Role-Based Access Control (RBAC) and how it helps enforce the principle of least privilege.
  3. What are the security risks associated with not deactivating employee accounts immediately after they leave the company?

Jawaban:

1.Security is no longer just about picking a strong password. In fact, relying solely on passwords has become a massive liability. That’s why Multi-Factor Authentication (MFA) is so critical—it moves away from that “single point of failure” by layering different types of credentials. The logic is simple: even if a hacker managed to snag your password through a phishing link or a data breach, they’d still be stuck. They can’t get in without that second or third piece of the puzzle.

When we talk about these “factors,” we’re usually looking at a combination of things. It’s not just “something you know” (your password), but also:

  • Something you have: This is usually the most practical layer, like a physical security key, a smart card, or more commonly, your phone for an authenticator app or a quick SMS code.
  • Something you are: This brings in biometrics—things like your fingerprint or facial recognition—which are much harder for someone else to replicate.

By forcing an attacker to bypass multiple, independent hurdles, MFA basically shuts the door on most automated attacks. Some estimates even suggest it can block over 99% of account compromises. Essentially, it turns a vulnerable account into a much harder target, making it one of the most effective ways to protect digital identities today.

2. Basically, Role-Based Access Control—or RBAC, as most people call it—is just a smarter way to handle who gets into what within a network. Instead of the headache of manually assigning permissions to every single person in a company, we just link those permissions to specific “roles,” like a Marketing Manager or a System Admin. Once that’s set up, you just drop a user into the right bucket, and they’re good to go.

One of the biggest reasons this works so well is that it makes enforcing the “Principle of Least Privilege” (PoLP) actually doable. The whole idea behind PoLP is that no one should have more access than they absolutely need to do their job.

RBAC helps keep this in check in a few ways:

First off, it lets us get really granular with roles. You can make sure a Developer has everything they need for coding, without accidentally giving them a peek into HR files or payroll. It also stops “permission creep” in its tracks. In a lot of places, people tend to collect access rights like souvenirs as they move through different projects, but RBAC keeps things standardized.

Lastly, it just makes life easier for whoever is managing the system. If someone changes departments, you don’t have to hunt down every individual permission they ever had. You just switch their role, and the system automatically swaps their old access for the new ones. It’s a lot cleaner and way less prone to human error.

3. Why We Can’t Just Leave Former Employees’ Accounts Active

When an employee leaves a company, you’d think closing their access is a standard “day one” task. But in reality, it often gets pushed back, and that’s where the trouble starts. Leaving these “orphan accounts” active isn’t just a minor oversight; it’s a massive open door for several security risks that can hit a company hard.

First off, there’s the obvious risk of a disgruntled former employee. If someone leaves on bad terms and still has their login info, there’s nothing stopping them from logging back in to wipe a database or leak proprietary stuff just out of spite. It’s a classic insider threat scenario, but it happens more often than people realize.

Then there’s the hijacking risk. These old accounts usually fly under the radar because nobody is monitoring them anymore. If a hacker finds a live account that hasn’t been touched in months, they can use it to move around the network. To the system, it looks like a “trusted” user is active, so it might not even trigger any security alerts until the damage is already done.

Beyond just the technical side, you have to consider compliance. If a company is under GDPR or HIPAA, they’re legally required to control who sees what. Failing an audit or getting hit with a massive fine just because an intern from two years ago still has access to the cloud storage is a pretty embarrassing (and expensive) way to learn that lesson. It’s basically a data leak waiting to happen, especially with how many SaaS apps we use nowadays that people can still access from their personal phones.

A Quick Breakdown: Authentication vs. Authorization

It’s easy to mix these two up, but they handle very different parts of the security process. Here’s how I usually differentiate them:

Concept

What it actually means

Practical Example

Authentication

This is just proving you are who you say you are. It’s the “ID check” at the door—typing in your password and hitting the MFA prompt.
Authorization This is about what you’re allowed to do once you’re inside.

Even if both a manager and an intern are “authenticated,” only the manager has the permissions to sign off on a budget.

 

Previous Post Previous Post
Newer Post Newer Post

Leave a comment