<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>DEV Community: Ridwan WH</title>
    <description>The latest articles on DEV Community by Ridwan WH (@ridwanwh).</description>
    <link>https://dev.to/ridwanwh</link>
    <image>
      <url>https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F1678843%2F697583fd-6b12-4db9-bedf-402d7fe1131c.png</url>
      <title>DEV Community: Ridwan WH</title>
      <link>https://dev.to/ridwanwh</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://dev.to/feed/ridwanwh"/>
    <language>en</language>
    <item>
      <title>Understanding Access Management</title>
      <dc:creator>Ridwan WH</dc:creator>
      <pubDate>Mon, 20 Apr 2026 05:54:55 +0000</pubDate>
      <link>https://dev.to/ridwanwh/understanding-access-management-56p2</link>
      <guid>https://dev.to/ridwanwh/understanding-access-management-56p2</guid>
      <description>&lt;p&gt;&lt;strong&gt;Why Many Companies Have Permission Issues&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;In many growing companies, cloud permissions often become messy and hard to manage. This is not because teams do not care about security, but because they focus more on speed in the early stage. As the team grows, more people and systems need access. Without a clear structure, permissions quickly become unorganized.&lt;/p&gt;

&lt;p&gt;At the center of this topic is &lt;strong&gt;Identity and Access Management (IAM)&lt;/strong&gt;. &lt;br&gt;
IAM is like a security system that controls who can access what.&lt;/p&gt;

&lt;p&gt;To make it simple, imagine an office building:&lt;/p&gt;

&lt;p&gt;There is a security guard at the entrance, this is IAM checking who you are&lt;br&gt;
Each room (server, database, app) has a different door&lt;br&gt;
Not everyone can enter every room&lt;/p&gt;

&lt;p&gt;For example:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;A receptionist can enter the front desk area&lt;/li&gt;
&lt;li&gt;A developer can enter the server room&lt;/li&gt;
&lt;li&gt;Only a manager can enter the finance room&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;If everyone has a master key, then anyone can open every door. That is where the risk starts&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Common Issues&lt;/strong&gt;&lt;br&gt;
Here are common problems in simple terms:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;Everyone gets a master key (too many people have admin access)&lt;/li&gt;
&lt;li&gt;No clear roles (people do not know what access they should have)&lt;/li&gt;
&lt;li&gt;Old access still active (ex-employees or unused API keys still work)&lt;/li&gt;
&lt;li&gt;Shared keys (many people use the same password or API key)&lt;/li&gt;
&lt;li&gt;No regular checking (access is never reviewed)&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;&lt;strong&gt;Simple Example Case&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;Imagine this situation:&lt;/p&gt;

&lt;p&gt;A company gives all developers full access because they want to move fast. One day, a developer stores an API key on their laptop. The laptop gets compromised through a phishing site or a malicious download (for example, from a movie site with clickjacking), and because there is no proper monitoring, the key is stolen.&lt;/p&gt;

&lt;p&gt;Because that key is like a master key, the attacker can open all “doors”, delete important data, or even worse,shut down services&lt;/p&gt;

&lt;p&gt;This happens not because of a big attack, but because of too much access.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Simple Solution&lt;/strong&gt;&lt;br&gt;
The goal is to stay fast but also safe.&lt;/p&gt;

&lt;ol&gt;
&lt;li&gt;Use the Principle of Least Privilege&lt;/li&gt;
&lt;li&gt;Give each person only the key they need, not a master key&lt;/li&gt;
&lt;li&gt;Store keys safely using tools like 1Password&lt;/li&gt;
&lt;li&gt;Do not keep keys in laptops or code&lt;/li&gt;
&lt;li&gt;Avoid daily use of admin access&lt;/li&gt;
&lt;li&gt;Only use it when really needed&lt;/li&gt;
&lt;li&gt;Clean unused access&lt;/li&gt;
&lt;li&gt;Remove old keys and inactive users&lt;/li&gt;
&lt;/ol&gt;

&lt;p&gt;&lt;strong&gt;Practical Approach&lt;/strong&gt;&lt;br&gt;
A simple step-by-step way:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;Check all keys and access (Who has what? Which ones are risky?)&lt;/li&gt;
&lt;li&gt;Group people by role(developer, admin, finance, viewer..)&lt;/li&gt;
&lt;li&gt;Limit access per role (Not everyone needs access to everything)&lt;/li&gt;
&lt;li&gt;Use temporary access or better only give higher access only when needed, then remove it&lt;/li&gt;
&lt;li&gt;Monitor activity with logging&lt;/li&gt;
&lt;li&gt;Review regularly (Make sure no extra access is left behind)&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;In the end, small issues in access management can grow into serious problems if they are ignored. What looks minor today can become a major risk tomorrow.&lt;/p&gt;

&lt;p&gt;It is always better to prevent than to fix. By staying aware, reviewing access regularly, and applying simple security practices, you can avoid many unnecessary incidents.&lt;/p&gt;

&lt;p&gt;A clean and controlled permission system is not only about security, but also about building trust and stability as your system continues to grow.&lt;br&gt;
-Rid&lt;/p&gt;

</description>
      <category>cloudcomputing</category>
      <category>saas</category>
    </item>
  </channel>
</rss>
