ਜੇ ਪਾਸਵਰਡ ਤੋਂ ਬਿਨਾਂ ਕੰਮ ਚੱਲ ਸਕਦਾ ਹੈ, ਤਾਂ ਉਸਦੀ ਰੱਖਿਆ ਕਿਉਂ ਕਰੀਏ?

ਉਹ ਸਮੱਸਿਆ ਜਿਸਨੂੰ ਅਸੀਂ ਆਮ ਗੱਲ ਮੰਨਣ ਦੇ ਆਦੀ ਹੋ ਗਏ ਹਾਂ

ਲਗਭਗ ਹਰ ਵੈੱਬ ਐਪਲੀਕੇਸ਼ਨ ਦਾ ਇੱਕ ਪ੍ਰਸ਼ਾਸਕੀ ਪੈਨਲ ਹੁੰਦਾ ਹੈ। ਅਤੇ ਆਮ ਤੌਰ ’ਤੇ, ਉਸ ਪੈਨਲ ਲਈ ਲੌਗਇਨ ਪਤਾ, ਪ੍ਰਮਾਣੀਕਰਨ ਫਾਰਮ, ਯੂਜ਼ਰਨੇਮ ਅਤੇ ਪਾਸਵਰਡ ਵੀ ਹੁੰਦੇ ਹਨ।

ਅਸੀਂ ਇਸ ਬਣਤਰ ਦੇ ਇੰਨੇ ਆਦੀ ਹੋ ਗਏ ਹਾਂ ਕਿ ਲਗਭਗ ਇਹ ਸਵਾਲ ਪੁੱਛਣਾ ਹੀ ਛੱਡ ਦਿੱਤਾ ਹੈ: ਕੀ ਹਰ ਚੀਜ਼ ਦਾ ਇਸੇ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰਨਾ ਲਾਜ਼ਮੀ ਹੈ?

ਜਦੋਂ ਤੁਹਾਡੀ ਇੱਕ ਵੈੱਬਸਾਈਟ ਹੁੰਦੀ ਹੈ, ਤਾਂ ਇਹ ਸਮੱਸਿਆ ਖ਼ਾਸ ਨਹੀਂ ਲੱਗਦੀ। ਇੱਕ ਮਜ਼ਬੂਤ ਪਾਸਵਰਡ ਬਣਾਓ, ਦੋ-ਪੜਾਅ ਪ੍ਰਮਾਣੀਕਰਨ ਚਾਲੂ ਕਰੋ, ਲੌਗਇਨ ਕੋਸ਼ਿਸ਼ਾਂ ਦੀ ਹੱਦ ਲਗਾਓ—ਤੇ ਕੰਮ ਕਰਦੇ ਰਹੋ।

ਪਰ ਜਦੋਂ ਪ੍ਰੋਜੈਕਟਾਂ ਦੀ ਗਿਣਤੀ ਦਸ, ਵੀਹ ਜਾਂ ਤੀਹ ਹੋ ਜਾਵੇ, ਤਾਂ ਕੀ ਹੁੰਦਾ ਹੈ?

ਮੇਰੇ ਮਾਮਲੇ ਵਿੱਚ, ਗੱਲ DigiMeld ਈਕੋਸਿਸਟਮ ਦੀ ਹੈ, ਜਿਸ ਵਿੱਚ ਤੀਹ ਤੋਂ ਵੱਧ ਸੁਤੰਤਰ ਸਾਫਟਵੇਅਰ ਪ੍ਰੋਜੈਕਟ ਸ਼ਾਮਲ ਹਨ। ਹਰ ਇੱਕ ਦੀ ਆਪਣੀ ਆਰਕੀਟੈਕਚਰ, ਸਰਵਰ ਲੌਜਿਕ ਅਤੇ ਪ੍ਰਸ਼ਾਸਕੀ ਇੰਟਰਫੇਸ ਹੈ।

ਇਸ ਲਈ, ਹਰ ਇੱਕ ਨੂੰ ਪ੍ਰਸ਼ਾਸਕੀ ਪਹੁੰਚ ਲਈ ਇੱਕ ਵਿਧੀ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।

ਲੰਮੇ ਸਮੇਂ ਤੱਕ ਮੈਂ ਕਾਫ਼ੀ ਰਵਾਇਤੀ ਤਰੀਕਾ ਵਰਤਿਆ: ਵੱਖਰੇ ਪ੍ਰਸ਼ਾਸਕੀ ਖਾਤੇ, ਮਜ਼ਬੂਤ ਪਾਸਵਰਡ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਬ੍ਰਾਊਜ਼ਰ ਵਿੱਚ ਸੰਭਾਲ ਕੇ ਰੱਖਣਾ।

ਇਹ ਕੰਮ ਕਰਦਾ ਸੀ।

ਪਰ ਇੱਕ ਮੋੜ ’ਤੇ ਮੈਂ ਸੋਚਿਆ: ਮੈਨੂੰ ਇੰਨੇ ਸਾਰੇ ਪ੍ਰਸ਼ਾਸਕੀ ਪਾਸਵਰਡ ਸੰਭਾਲ ਕੇ ਰੱਖਣ ਦੀ ਲੋੜ ਹੀ ਕਿਉਂ ਹੈ? ਮੈਨੂੰ ਸਿਰਫ਼ ਸਰਵਰਾਂ ਦੀ ਹੀ ਨਹੀਂ, ਸਗੋਂ ਉਹਨਾਂ ਤੱਕ ਪਹੁੰਚਣ ਦੇ ਸਾਧਨਾਂ ਦੀ ਵੀ ਰੱਖਿਆ ਕਿਉਂ ਕਰਨੀ ਪੈਂਦੀ ਹੈ?

ਕੀ ਇਸ ਲੋੜ ਤੋਂ ਬਚਿਆ ਨਹੀਂ ਜਾ ਸਕਦਾ?

ਮੈਂ ਇਸ ਵਿਚਾਰ ਤੱਕ ਪਹੁੰਚਿਆ, ਜੋ ਬਾਅਦ ਵਿੱਚ ਮੇਰੇ ਹੱਲ ਦਾ ਆਧਾਰ ਬਣਿਆ:

ਸ਼ਾਇਦ ਲਗਾਤਾਰ ਮੌਜੂਦ ਲੌਗਇਨ ਦੀ ਰੱਖਿਆ ਕਰਨ ਦੀ ਬਜਾਏ, ਕੁਝ ਸਮੇਂ ਲਈ ਪਹੁੰਚ ਹਾਸਲ ਕਰਨ ਦੇ ਅਧਿਕਾਰ ਦੀ ਰੱਖਿਆ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ।

ਇੱਕ ਮਜ਼ਬੂਤ ਪਾਸਵਰਡ ਮੂਲ ਸਮੱਸਿਆ ਨੂੰ ਖ਼ਤਮ ਨਹੀਂ ਕਰਦਾ

ਆਧੁਨਿਕ ਸਾਧਨਾਂ ਨਾਲ ਬਹੁਤ ਉੱਚੀ ਐਂਟਰੋਪੀ ਵਾਲੇ ਪਾਸਵਰਡ ਬਣਾਏ ਜਾ ਸਕਦੇ ਹਨ। ਠੀਕ ਤਰੀਕੇ ਨਾਲ ਬਣਾਇਆ ਗਿਆ ਲੰਮਾ, ਬੇਤਰਤੀਬ ਪਾਸਵਰਡ ਸਿੱਧੀ ਕੋਸ਼ਿਸ਼ ਨਾਲ ਲੱਭਣਾ ਲਗਭਗ ਅਸੰਭਵ ਹੁੰਦਾ ਹੈ।

ਪਰ ਪਾਸਵਰਡ ਭਾਵੇਂ ਕਿੰਨਾ ਵੀ ਮਜ਼ਬੂਤ ਹੋਵੇ, ਉਸਨੂੰ ਕਿਤੇ ਸੰਭਾਲਣਾ ਅਤੇ ਫਿਰ ਵਰਤਣਾ ਤਾਂ ਪੈਂਦਾ ਹੈ।

ਪਾਸਵਰਡ ਮੈਨੇਜਰ, ਹਾਰਡਵੇਅਰ ਕੁੰਜੀਆਂ, ਬਹੁ-ਕਾਰਕੀ ਪ੍ਰਮਾਣੀਕਰਨ ਅਤੇ ਵਾਧੂ ਪਾਬੰਦੀਆਂ ਵਰਤੀਆਂ ਜਾ ਸਕਦੀਆਂ ਹਨ। ਇਹ ਸਭ ਵਾਕਈ ਸੁਰੱਖਿਆ ਵਧਾਉਂਦੇ ਹਨ।

ਫਿਰ ਵੀ, ਮੂਲ ਢਾਂਚਾ ਕਾਇਮ ਰਹਿੰਦਾ ਹੈ: ਇੱਕ ਖ਼ਾਸ ਇੰਟਰਫੇਸ ਹੁੰਦਾ ਹੈ ਜਿਸ ਰਾਹੀਂ ਯੂਜ਼ਰ ਆਪਣੇ ਖਾਤੇ ਦੇ ਵੇਰਵੇ ਦਿੰਦਾ ਹੈ।

ਉਸ ’ਤੇ ਬੇਨਤੀਆਂ ਭੇਜੀਆਂ ਜਾ ਸਕਦੀਆਂ ਹਨ। ਉਸਨੂੰ ਸਕੈਨ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਉਹ ਆਟੋਮੈਟਿਕ ਹਮਲਿਆਂ ਦਾ ਨਿਸ਼ਾਨਾ ਬਣ ਸਕਦਾ ਹੈ।

ਪ੍ਰਸ਼ਾਸਕੀ ਪੈਨਲ ਦਾ ਪਤਾ ਲੁਕਾਇਆ ਜਾ ਸਕਦਾ ਹੈ, ਮਿਆਰੀ ਰਸਤੇ ਦੀ ਥਾਂ ਅੱਖਰਾਂ ਦੀ ਲੰਮੀ ਬੇਤਰਤੀਬ ਲੜੀ ਰੱਖੀ ਜਾ ਸਕਦੀ ਹੈ ਜਾਂ IP ਦੇ ਆਧਾਰ ’ਤੇ ਪਹੁੰਚ ਸੀਮਤ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ।

ਪਰ ਫਿਰ ਇੱਕ ਨਵਾਂ ਸਵਾਲ ਉੱਠਦਾ ਹੈ: ਇਹ ਪਤਾ ਕਿੱਥੇ ਸੰਭਾਲਣਾ ਹੈ ਅਤੇ ਇਸਦੀ ਵਰਤੋਂ ਕਿਵੇਂ ਕਰਨੀ ਹੈ?

ਅਤੇ ਸਭ ਤੋਂ ਅਹਿਮ ਗੱਲ—ਜਦੋਂ ਪ੍ਰਸ਼ਾਸਕੀ ਪਹੁੰਚ ਦੀ ਲੋੜ ਸਿਰਫ਼ ਖ਼ਾਸ ਮੌਕਿਆਂ ’ਤੇ ਹੁੰਦੀ ਹੈ, ਤਾਂ ਲਗਾਤਾਰ ਮੌਜੂਦ ਲੌਗਇਨ ਬਿੰਦੂ ਕਾਇਮ ਰੱਖਣ ਦੀ ਲੋੜ ਹੀ ਕੀ ਹੈ?

ਮੈਂ ਇਸ ਵਿਚਾਰ ਤੱਕ ਪਹੁੰਚਿਆ, ਜੋ ਬਾਅਦ ਵਿੱਚ ਮੇਰੇ ਹੱਲ ਦਾ ਆਧਾਰ ਬਣਿਆ:

ਸ਼ਾਇਦ ਲਗਾਤਾਰ ਮੌਜੂਦ ਲੌਗਇਨ ਦੀ ਰੱਖਿਆ ਕਰਨ ਦੀ ਬਜਾਏ, ਕੁਝ ਸਮੇਂ ਲਈ ਪਹੁੰਚ ਹਾਸਲ ਕਰਨ ਦੇ ਅਧਿਕਾਰ ਦੀ ਰੱਖਿਆ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ।

ਜੇ ਰਵਾਇਤੀ ਲੌਗਇਨ ਪੰਨਾ ਹੋਵੇ ਹੀ ਨਾ ਤਾਂ?

ਮੈਂ ਆਪਣੇ ਪ੍ਰੋਜੈਕਟਾਂ ਵਿੱਚ ਪ੍ਰਸ਼ਾਸਕੀ ਪ੍ਰਮਾਣੀਕਰਨ ਦੇ ਰਵਾਇਤੀ ਮਾਡਲ ਨੂੰ ਛੱਡਣ ਦਾ ਫ਼ੈਸਲਾ ਕੀਤਾ।

ਸਿਰਫ਼ ਲੌਗਇਨ ਫਾਰਮ ਲੁਕਾਉਣਾ ਨਹੀਂ।

ਪਤੇ ਦਾ ਨਾਂ ਬਦਲਣਾ ਨਹੀਂ।

ਪਾਸਵਰਡ ਦੀ ਥਾਂ ਹੋਰ ਵੀ ਔਖਾ ਪਾਸਵਰਡ ਰੱਖਣਾ ਨਹੀਂ।

ਸਗੋਂ ਲਗਾਤਾਰ ਮੌਜੂਦ ਪਾਸਵਰਡ-ਆਧਾਰਿਤ ਲੌਗਇਨ ਦੀ ਲੋੜ ਹੀ ਖ਼ਤਮ ਕਰਨੀ।

ਬੇਸ਼ੱਕ, ਪ੍ਰਸ਼ਾਸਕੀ ਇੰਟਰਫੇਸ ਕਿਤੇ ਗਾਇਬ ਨਹੀਂ ਹੋਏ। ਐਪਲੀਕੇਸ਼ਨਾਂ ਦੇ ਪ੍ਰਬੰਧਨ ਲਈ ਉਹ ਅਜੇ ਵੀ ਲੋੜੀਂਦੇ ਹਨ।

ਬਦਲਿਆ ਸਿਰਫ਼ ਉਹ ਤਰੀਕਾ ਹੈ ਜਿਸ ਨਾਲ ਉਹਨਾਂ ਤੱਕ ਪਹੁੰਚ ਮਿਲਦੀ ਹੈ।

ਹੁਣ ਜੁੜੇ ਹੋਏ ਪ੍ਰੋਜੈਕਟਾਂ ਦੇ ਪ੍ਰਸ਼ਾਸਕੀ ਪੈਨਲਾਂ ਵਿੱਚ ਦਾਖ਼ਲ ਹੋਣ ਲਈ ਸੰਭਾਲਿਆ ਹੋਇਆ ਯੂਜ਼ਰਨੇਮ ਅਤੇ ਪਾਸਵਰਡ ਲਿਖਣ ਦੀ ਲੋੜ ਨਹੀਂ ਪੈਂਦੀ।

ਇਸ ਦੀ ਬਜਾਏ, ਮੈਂ ਆਪਣਾ ਪਛਾਣ ਅਤੇ ਪਹੁੰਚ ਪ੍ਰਬੰਧਨ ਸਿਸਟਮ MeldID ਵਰਤਦਾ ਹਾਂ।

ਇਸਦਾ ਮੂਲ ਵਿਚਾਰ ਸੌਖਾ ਹੈ: ਪ੍ਰਸ਼ਾਸਕੀ ਪਹੁੰਚ ਸਿਰਫ਼ ਉਦੋਂ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ ਜਦੋਂ ਇਸਦੀ ਸੱਚਮੁੱਚ ਲੋੜ ਹੋਵੇ—ਕਿਸੇ ਖ਼ਾਸ ਯੂਜ਼ਰ ਨੂੰ, ਕਿਸੇ ਖ਼ਾਸ ਪ੍ਰੋਜੈਕਟ ਲਈ।

ਅਤੇ ਸਿਰਫ਼ ਖਾਤਾ ਹੋਣ ਦਾ ਮਤਲਬ ਇਹ ਨਹੀਂ ਕਿ ਯੂਜ਼ਰ ਨੂੰ ਪ੍ਰਸ਼ਾਸਕੀ ਪੈਨਲ ਖੋਲ੍ਹਣ ਦਾ ਅਧਿਕਾਰ ਵੀ ਹੈ।

ਇਹ ਅਧਿਕਾਰ ਵੱਖਰੇ ਤੌਰ ’ਤੇ ਦੇਣਾ ਪੈਂਦਾ ਹੈ।

ਉਹ ਪਹੁੰਚ ਜੋ ਇੱਕ ਮਿੰਟ ਪਹਿਲਾਂ ਮੌਜੂਦ ਨਹੀਂ ਸੀ

ਸ਼ਾਇਦ ਇਹ ਪੂਰੀ ਸੋਚ ਦਾ ਸਭ ਤੋਂ ਦਿਲਚਸਪ ਹਿੱਸਾ ਹੈ।

ਰਵਾਇਤੀ ਮਾਡਲ ਵਿੱਚ ਪ੍ਰਸ਼ਾਸਕ ਕੋਲ ਲੌਗਇਨ ਦੇ ਸਾਧਨ ਲਗਾਤਾਰ ਮੌਜੂਦ ਹੁੰਦੇ ਹਨ। ਜਦ ਤੱਕ ਉਹ ਸਾਧਨ ਵੈਧ ਰਹਿੰਦੇ ਹਨ, ਉਹ ਅੱਜ, ਕੱਲ੍ਹ ਜਾਂ ਇੱਕ ਮਹੀਨੇ ਬਾਅਦ ਵੀ ਉਹਨਾਂ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦਾ ਹੈ।

ਮੈਂ ਇਸ ਅਸੂਲ ਨੂੰ ਬਦਲਣ ਦਾ ਫ਼ੈਸਲਾ ਕੀਤਾ।

ਸਥਾਈ ਪ੍ਰਸ਼ਾਸਕੀ ਖਾਤਾ-ਵੇਰਵਿਆਂ ਦੀ ਥਾਂ, ਲੌਗਇਨ ਸ਼ੁਰੂ ਕਰਨ ਦੀ ਅਸਥਾਈ ਸੰਭਾਵਨਾ ਵਰਤੀ ਜਾਂਦੀ ਹੈ।

ਇਹ ਭਰੋਸੇਯੋਗ ਮੋਬਾਈਲ ਡਿਵਾਈਸ ਰਾਹੀਂ ਬੇਨਤੀ ਕਰਨ ’ਤੇ ਬਣਾਈ ਜਾਂਦੀ ਹੈ, ਇਸ ਵਿੱਚ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫ਼ਿਕ ਤੌਰ ’ਤੇ ਮਜ਼ਬੂਤ ਬੇਤਰਤੀਬ ਹਿੱਸਾ ਹੁੰਦਾ ਹੈ ਅਤੇ ਇਸਦੀ ਮਿਆਦ ਸੀਮਤ ਹੁੰਦੀ ਹੈ।

ਪਰ ਸਿਰਫ਼ ਇਸ ਅਸਥਾਈ ਲਿੰਕ ਦਾ ਹੋਣਾ ਵੀ ਆਪਣੇ ਆਪ ਪਹੁੰਚ ਨਹੀਂ ਦਿੰਦਾ।

ਇਹ ਇੱਕ ਬੁਨਿਆਦੀ ਗੱਲ ਹੈ।

ਮੰਨ ਲਓ ਕਿਸੇ ਨੂੰ ਕਿਸੇ ਤਰੀਕੇ ਨਾਲ ਇਹ ਲਿੰਕ ਮਿਲ ਜਾਂਦਾ ਹੈ। ਸਿਰਫ਼ ਪਤੇ ਦੀ ਗੁਪਤਤਾ ’ਤੇ ਆਧਾਰਿਤ ਆਮ ਸਿਸਟਮ ਵਿੱਚ, ਇਸਦਾ ਲੀਕ ਹੋਣਾ ਗੰਭੀਰ ਸਮੱਸਿਆ ਬਣ ਸਕਦਾ ਸੀ।

ਮੇਰੇ ਮਾਡਲ ਵਿੱਚ, ਲਿੰਕ ਸਿਰਫ਼ ਪੁਸ਼ਟੀ ਦੀ ਪ੍ਰਕਿਰਿਆ ਸ਼ੁਰੂ ਕਰਨ ਦਿੰਦਾ ਹੈ।

ਅੱਗੇ ਵਧਣ ਲਈ MeldID ਦੀ ਭਰੋਸੇਯੋਗ ਮੋਬਾਈਲ ਡਿਵਾਈਸ ਰਾਹੀਂ ਵੱਖਰੀ ਮਨਜ਼ੂਰੀ ਲੋੜੀਂਦੀ ਹੈ।

ਇਸ ਪੁਸ਼ਟੀ ਤੋਂ ਬਿਨਾਂ ਪ੍ਰਸ਼ਾਸਕੀ ਸੈਸ਼ਨ ਨਹੀਂ ਬਣਾਇਆ ਜਾਂਦਾ।

ਇਸੇ ਲਈ ਮੈਂ ਅਸਥਾਈ ਲਿੰਕ ਨੂੰ ਪਾਸਵਰਡ ਦਾ ਬਦਲ ਨਹੀਂ, ਸਗੋਂ ਪਹੁੰਚ ਦੇਣ ਦੀ ਪ੍ਰਕਿਰਿਆ ਦਾ ਇੱਕ ਹਿੱਸਾ ਮੰਨਦਾ ਹਾਂ।

ਇਹ ਜਾਣਨਾ ਕਿ ਕਿੱਥੇ ਜਾਣਾ ਹੈ ਅਤੇ ਅੰਦਰ ਜਾਣ ਦਾ ਅਧਿਕਾਰ ਹੋਣਾ—ਦੋ ਬਿਲਕੁਲ ਵੱਖਰੀਆਂ ਗੱਲਾਂ ਹਨ।

ਫ਼ੋਨ ਪਹੁੰਚ ਪ੍ਰਬੰਧਨ ਦਾ ਸਾਧਨ ਬਣ ਜਾਂਦਾ ਹੈ

ਇਸ ਮਾਡਲ ਵਿੱਚ ਮੋਬਾਈਲ ਡਿਵਾਈਸ ਦੀ ਭੂਮਿਕਾ ਇੱਕ ਆਮ ਵਨ-ਟਾਈਮ ਕੋਡ ਜਨਰੇਟਰ ਨਾਲੋਂ ਕਾਫ਼ੀ ਅਹਿਮ ਹੈ।

ਇਹ ਪ੍ਰਸ਼ਾਸਕੀ ਪਹੁੰਚ ਨਾਲ ਜੁੜੀਆਂ ਕਾਰਵਾਈਆਂ ਦੀ ਪੁਸ਼ਟੀ ਕਰਨ ਲਈ ਵਰਤੀ ਜਾਂਦੀ ਹੈ।

ਜਦੋਂ ਮੈਂ ਪ੍ਰਸ਼ਾਸਕੀ ਪੈਨਲ ਖੋਲ੍ਹਣਾ ਚਾਹੁੰਦਾ ਹਾਂ, ਤਾਂ ਸਿਸਟਮ MeldID ਰਾਹੀਂ ਪੁਸ਼ਟੀ ਮੰਗਦਾ ਹੈ।

ਮੈਨੂੰ ਭਰੋਸੇਯੋਗ ਡਿਵਾਈਸ ’ਤੇ ਸੰਬੰਧਿਤ ਬੇਨਤੀ ਦਿਖਾਈ ਦਿੰਦੀ ਹੈ ਅਤੇ ਮੈਂ ਕਾਰਵਾਈ ਦੀ ਪੁਸ਼ਟੀ ਕਰਦਾ ਹਾਂ।

ਜਾਂਚ ਸਫ਼ਲ ਹੋਣ ਤੋਂ ਬਾਅਦ ਹੀ ਸਿਸਟਮ ਲੌਗਇਨ ਦੀ ਪ੍ਰਕਿਰਿਆ ਜਾਰੀ ਰੱਖਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ।

ਇਹ ਪੁਸ਼ਟੀ ਕਿਸੇ ਖ਼ਾਸ ਕਾਰਵਾਈ ਨਾਲ ਜੁੜੀ ਹੁੰਦੀ ਹੈ, ਨਾ ਕਿ ਸਿਰਫ਼ ਇਸ ਗੱਲ ਨਾਲ ਕਿ ਫ਼ੋਨ ਅਨਲੌਕ ਕੀਤਾ ਗਿਆ ਹੈ।

ਮੋਬਾਈਲ ਬਾਇਓਮੈਟ੍ਰਿਕਸ ਡਿਵਾਈਸ ’ਤੇ ਹੀ ਯੂਜ਼ਰ ਦੀ ਜਾਂਚ ਕਰਦੇ ਹਨ, ਜਦਕਿ ਸਰਵਰ ਪਾਸੇ ਰਜਿਸਟਰ ਕੀਤੀ ਡਿਵਾਈਸ ਤੋਂ ਆਈ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫ਼ਿਕ ਪੁਸ਼ਟੀ ਦੀ ਜਾਂਚ ਹੁੰਦੀ ਹੈ।

ਇਸ ਤਰੀਕੇ ਨਾਲ ਸਿਰਫ਼ ਪਾਸਵਰਡ ਜਾਂ ਇਸ ਸੁਨੇਹੇ ’ਤੇ ਨਿਰਭਰ ਨਹੀਂ ਰਹਿਣਾ ਪੈਂਦਾ ਕਿ ਯੂਜ਼ਰ ਨੇ ਕਥਿਤ ਤੌਰ ’ਤੇ ਲੌਗਇਨ ਦੀ ਪੁਸ਼ਟੀ ਕਰ ਦਿੱਤੀ ਹੈ।

ਇੱਥੇ ਇੱਕ ਹੋਰ ਫ਼ਾਇਦਾ ਵੀ ਹੈ: ਭਰੋਸੇਯੋਗ ਡਿਵਾਈਸਾਂ ਦਾ ਪ੍ਰਬੰਧਨ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।

ਜੇ ਕਿਸੇ ਡਿਵਾਈਸ ਨੂੰ ਹੁਣ ਪਹੁੰਚ ਦੀ ਪੁਸ਼ਟੀ ਲਈ ਵਰਤਣਾ ਨਹੀਂ ਚਾਹੀਦਾ, ਤਾਂ ਉਸਦਾ ਭਰੋਸੇਯੋਗ ਦਰਜਾ ਰੱਦ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।

ਇਸ ਤੋਂ ਬਾਅਦ ਉਹ ਸੰਬੰਧਿਤ ਕਾਰਵਾਈਆਂ ਲਈ ਪ੍ਰਮਾਣੀਕਰਨ ਦਾ ਸਰਗਰਮ ਸਾਧਨ ਨਹੀਂ ਰਹਿੰਦੀ।

ਇੱਕ ਸਿਸਟਮ—ਕਈ ਸੁਤੰਤਰ ਪ੍ਰੋਜੈਕਟ

ਜਦੋਂ ਮੈਂ ਇਹ ਵਿਧੀ ਵਿਕਸਿਤ ਕਰਨੀ ਸ਼ੁਰੂ ਕੀਤੀ, ਤਾਂ ਮੁੱਖ ਕੰਮਾਂ ਵਿੱਚੋਂ ਇੱਕ ਹਰ ਪ੍ਰੋਜੈਕਟ ਦੀ ਸੁਤੰਤਰਤਾ ਕਾਇਮ ਰੱਖਣਾ ਸੀ।

ਮੈਂ ਸਾਰੇ ਪ੍ਰਸ਼ਾਸਕੀ ਪੈਨਲਾਂ ਨੂੰ ਇੱਕ ਵਿਸ਼ਾਲ ਐਪਲੀਕੇਸ਼ਨ ਵਿੱਚ ਨਹੀਂ ਜੋੜਨਾ ਚਾਹੁੰਦਾ ਸੀ।

DigiMeld ਦੀ ਹਰ ਸੇਵਾ ਨੂੰ ਆਪਣੇ ਲੌਜਿਕ, ਸੈਟਿੰਗਾਂ, ਯੂਜ਼ਰਾਂ ਅਤੇ ਡਾਟੇ ਦਾ ਪ੍ਰਬੰਧਨ ਖ਼ੁਦ ਕਰਦੇ ਰਹਿਣਾ ਸੀ।

ਇਸ ਲਈ ਮੈਂ ਦੋ ਕੰਮ ਵੱਖ ਕਰ ਦਿੱਤੇ।

MeldID ਪਛਾਣ ਅਤੇ ਪ੍ਰਸ਼ਾਸਕੀ ਪਹੁੰਚ ਦੇਣ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਹੈ।

ਜਦਕਿ ਹਰ ਪ੍ਰੋਜੈਕਟ ਆਪਣੇ ਪ੍ਰਸ਼ਾਸਕੀ ਕੰਮਾਂ ਅਤੇ ਮੌਜੂਦਾ ਅਧਿਕਾਰਾਂ ਦੀ ਜਾਂਚ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਹੈ।

ਇਸ ਤਰ੍ਹਾਂ, ਐਪਲੀਕੇਸ਼ਨਾਂ ਨੂੰ ਕੇਂਦਰੀਕ੍ਰਿਤ ਕੀਤੇ ਬਿਨਾਂ ਪਹੁੰਚ ਪ੍ਰਬੰਧਨ ਦਾ ਇੱਕ ਕੇਂਦਰੀ ਮਾਡਲ ਬਣ ਗਿਆ।

ਇਸ ਤੋਂ ਇਲਾਵਾ, ਅਧਿਕਾਰ ਵੱਖਰੇ ਤੌਰ ’ਤੇ ਦਿੱਤੇ ਜਾਂਦੇ ਹਨ।

ਇੱਕ ਪ੍ਰੋਜੈਕਟ ਦਾ ਪ੍ਰਸ਼ਾਸਕ ਸਿਰਫ਼ MeldID ਖਾਤਾ ਹੋਣ ਕਰਕੇ ਆਪਣੇ ਆਪ ਬਾਕੀ ਪ੍ਰੋਜੈਕਟਾਂ ਤੱਕ ਪਹੁੰਚ ਨਹੀਂ ਲੈਂਦਾ।

ਹਰ ਪ੍ਰਸ਼ਾਸਕੀ ਖੇਤਰ ਲਈ ਅਧਿਕਾਰ ਪ੍ਰਾਪਤ ਯੂਜ਼ਰਾਂ ਦਾ ਆਪਣਾ ਸਮੂਹ ਤੈਅ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।

ਆਮ ਯੂਜ਼ਰਾਂ ਦੇ ਅਧਿਕਾਰ ਅਤੇ ਪ੍ਰਸ਼ਾਸਕੀ ਅਧਿਕਾਰ ਵੱਖਰੇ ਰਹਿੰਦੇ ਹਨ।

ਦਰਜਨਾਂ ਸੇਵਾਵਾਂ ਵਾਲੇ ਈਕੋਸਿਸਟਮ ਲਈ ਇਹ ਖ਼ਾਸ ਤੌਰ ’ਤੇ ਸੁਵਿਧਾਜਨਕ ਸਾਬਤ ਹੋਇਆ।

ਮੈਨੂੰ ਅਸਥਾਈ ਪਹੁੰਚ ਸਥਾਈ ਪਹੁੰਚ ਨਾਲੋਂ ਵਧੀਆ ਕਿਉਂ ਲੱਗਦੀ ਹੈ

ਇੱਕ ਹੋਰ ਅਸੂਲ ਵੀ ਹੈ ਜਿਸਨੂੰ ਮੈਂ ਜਾਣ-ਬੁੱਝ ਕੇ ਸਿਸਟਮ ਵਿੱਚ ਸ਼ਾਮਲ ਕੀਤਾ।

ਪ੍ਰਸ਼ਾਸਕੀ ਪਹੁੰਚ ਬੇਅੰਤ ਸਮੇਂ ਲਈ ਕਾਇਮ ਨਹੀਂ ਰਹਿਣੀ ਚਾਹੀਦੀ।

ਮਨਜ਼ੂਰੀ ਸੀਮਤ ਸਮੇਂ ਲਈ ਵੈਧ ਰਹਿੰਦੀ ਹੈ ਅਤੇ ਇਸਦੀ ਮਿਆਦ ਮੁੱਕਣ ’ਤੇ ਖ਼ਤਮ ਹੋ ਜਾਂਦੀ ਹੈ—ਭਾਵੇਂ ਯੂਜ਼ਰ ਬ੍ਰਾਊਜ਼ਰ ਵਿੱਚ ਕੰਮ ਕਰਦਾ ਰਹੇ।

ਮਿਆਦ ਪੂਰੀ ਹੋਣ ਤੋਂ ਬਾਅਦ ਕੰਮ ਜਾਰੀ ਰੱਖਣ ਲਈ ਪੁਸ਼ਟੀ ਦੀ ਨਵੀਂ ਪ੍ਰਕਿਰਿਆ ਲੋੜੀਂਦੀ ਹੁੰਦੀ ਹੈ।

ਇਸ ਨਾਲ ਇੱਕ ਵਾਰ ਕੀਤੇ ਪ੍ਰਮਾਣੀਕਰਨ ਨੂੰ ਲਗਾਤਾਰ ਵੈਧ ਰਹਿਣ ਵਾਲੇ ਅਧਿਕਾਰ ਵਿੱਚ ਬਦਲਣ ਤੋਂ ਰੋਕਿਆ ਜਾ ਸਕਦਾ ਹੈ।

ਪਰ ਸਿਰਫ਼ ਸਮੇਂ ਦੀ ਹੱਦ ਕਾਫ਼ੀ ਨਹੀਂ।

ਪਹਿਲਾਂ ਦਿੱਤੀ ਪਹੁੰਚ ਨੂੰ ਸਮੇਂ ਤੋਂ ਪਹਿਲਾਂ ਖ਼ਤਮ ਕਰਨ ਦੀ ਸੰਭਾਵਨਾ ਵੀ ਅਹਿਮ ਹੈ।

ਇਸ ਲਈ MeldID ਵਿੱਚ ਪ੍ਰਸ਼ਾਸਕੀ ਮਨਜ਼ੂਰੀਆਂ ਰੱਦ ਕਰਨ ਦੀ ਕੇਂਦਰੀ ਵਿਵਸਥਾ ਹੈ।

ਜਦੋਂ ਮਨਜ਼ੂਰੀ ਰੱਦ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਜੁੜੇ ਹੋਏ ਪ੍ਰੋਜੈਕਟਾਂ ਨੂੰ ਇਸ ਬਾਰੇ ਘਟਨਾ-ਸੂਚਨਾ ਮਿਲਦੀ ਹੈ ਅਤੇ ਉਹ ਸੰਬੰਧਿਤ ਪ੍ਰਸ਼ਾਸਕੀ ਸੈਸ਼ਨ ਰੱਦ ਕਰ ਦਿੰਦੇ ਹਨ।

ਇਸ ਤਰ੍ਹਾਂ, ਜਦੋਂ ਯੂਜ਼ਰ ਸਫ਼ਲਤਾਪੂਰਵਕ ਲੌਗਇਨ ਕਰ ਲੈਂਦਾ ਹੈ, ਤਾਂ ਪਹੁੰਚ ਦਾ ਪ੍ਰਬੰਧਨ ਖ਼ਤਮ ਨਹੀਂ ਹੋ ਜਾਂਦਾ।

ਮੇਰੇ ਲਈ ਅਧਿਕਾਰ ਦੇਣ ਦੀ ਸਮਰੱਥਾ ਜਿੰਨੀ ਹੀ ਅਹਿਮ, ਉਹਨਾਂ ਨੂੰ ਰੱਦ ਕਰਨ ਦੀ ਸਮਰੱਥਾ ਵੀ ਹੈ।

ਇਸ ਦੇ ਨਾਲ ਹੀ, ਵੰਡੇ ਹੋਏ ਸਿਸਟਮ ਨੂੰ ਘਟਨਾਵਾਂ ਦੀ ਪਹੁੰਚ ਵਿੱਚ ਦੇਰੀ, ਕੁਝ ਹਿੱਸਿਆਂ ਦੀ ਅਸਥਾਈ ਅਣਉਪਲਬਧਤਾ ਅਤੇ ਕੰਮਕਾਜ ਨਾਲ ਜੁੜੀਆਂ ਹੋਰ ਸਥਿਤੀਆਂ ਨੂੰ ਵੀ ਧਿਆਨ ਵਿੱਚ ਰੱਖਣਾ ਚਾਹੀਦਾ ਹੈ। ਸੈਸ਼ਨਾਂ ਦੀ ਮਿਆਦ ਸੀਮਤ ਰੱਖਣਾ ਇੱਕ ਵਾਧੂ ਸੁਰੱਖਿਆ ਹੱਦ ਵਜੋਂ ਕੰਮ ਕਰਦਾ ਹੈ।

ਰੋਜ਼ਾਨਾ ਦੇ ਕੰਮ ਵਿੱਚ ਕੀ ਬਦਲਿਆ?

ਸਭ ਤੋਂ ਪਹਿਲਾਂ, ਸੰਭਾਲੇ ਹੋਏ ਪ੍ਰਸ਼ਾਸਕੀ ਪਾਸਵਰਡਾਂ ਦੀ ਲੋੜ ਖ਼ਤਮ ਹੋ ਗਈ।

ਹੁਣ ਮੈਨੂੰ ਹਰ ਜੁੜੇ ਹੋਏ ਪ੍ਰਸ਼ਾਸਕੀ ਪੈਨਲ ਵਿੱਚ ਦਾਖ਼ਲ ਹੋਣ ਲਈ ਖਾਤਾ-ਵੇਰਵਿਆਂ ਦਾ ਸੈੱਟ ਬ੍ਰਾਊਜ਼ਰ ਵਿੱਚ ਰੱਖਣ ਦੀ ਲੋੜ ਨਹੀਂ ਪੈਂਦੀ।

ਇਸ ਦੀ ਬਜਾਏ, ਮੈਂ ਇੱਕੋ ਵਿਧੀ ਰਾਹੀਂ ਮਨਜ਼ੂਰੀਆਂ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਦਾ ਹਾਂ।

ਲੋੜੀਂਦਾ ਪ੍ਰੋਜੈਕਟ ਚੁਣਦਾ ਹਾਂ, ਪਹੁੰਚ ਦੀ ਪੁਸ਼ਟੀ ਕਰਦਾ ਹਾਂ ਅਤੇ ਕੰਮ ਕਰਦਾ ਹਾਂ।

ਜਦੋਂ ਪ੍ਰਸ਼ਾਸਕੀ ਪਹੁੰਚ ਦੀ ਲੋੜ ਨਹੀਂ ਰਹਿੰਦੀ, ਤਾਂ ਇਸਨੂੰ ਰੱਦ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।

ਇਹ ਗੱਲ ਖ਼ਾਸ ਤੌਰ ’ਤੇ ਸੁਵਿਧਾਜਨਕ ਹੈ ਕਿ ਨਵਾਂ ਪ੍ਰੋਜੈਕਟ ਆਉਣ ’ਤੇ ਪ੍ਰਸ਼ਾਸਕੀ ਪ੍ਰਮਾਣੀਕਰਨ ਦਾ ਪੂਰਾ ਸਿਸਟਮ ਮੁੜ ਤਿਆਰ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ ਪੈਂਦੀ।

ਸਿਰਫ਼ ਉਸਨੂੰ ਮੌਜੂਦਾ ਮਾਡਲ ਨਾਲ ਜੋੜਨਾ ਅਤੇ ਲੋੜੀਂਦੀਆਂ ਮਨਜ਼ੂਰੀਆਂ ਤੈਅ ਕਰਨਾ ਕਾਫ਼ੀ ਹੈ।

ਬੇਸ਼ੱਕ, ਇਸਦਾ ਮਤਲਬ ਇਹ ਨਹੀਂ ਕਿ ਸੁਰੱਖਿਆ ਦੇ ਸਾਰੇ ਖ਼ਤਰੇ ਖ਼ਤਮ ਹੋ ਗਏ ਹਨ।

ਅਸਥਾਈ ਮਨਜ਼ੂਰੀਆਂ, ਭਰੋਸੇਯੋਗ ਡਿਵਾਈਸਾਂ, ਸਰਵਰ ਸੈਸ਼ਨਾਂ ਅਤੇ ਕੇਂਦਰੀ ਢਾਂਚੇ ਦੀ ਵੀ ਸੁਰੱਖਿਆ ਲੋੜੀਂਦੀ ਹੈ।

ਪਰ ਹੁਣ ਮੈਨੂੰ ਹਰ ਐਪਲੀਕੇਸ਼ਨ ਲਈ ਪ੍ਰਸ਼ਾਸਕੀ ਪਾਸਵਰਡਾਂ ਦੇ ਪ੍ਰਬੰਧਨ ਦੀ ਇੱਕੋ ਸਮੱਸਿਆ ਵੱਖਰੇ ਤੌਰ ’ਤੇ ਹੱਲ ਨਹੀਂ ਕਰਨੀ ਪੈਂਦੀ।

ਅਤੇ ਇਹੀ ਮੇਰੇ ਸ਼ੁਰੂਆਤੀ ਟੀਚਿਆਂ ਵਿੱਚੋਂ ਇੱਕ ਸੀ।

ਕੀ ਅਜਿਹੀਆਂ ਤਕਨੀਕਾਂ ਪਹਿਲਾਂ ਤੋਂ ਮੌਜੂਦ ਨਹੀਂ ਹਨ?

ਬੇਸ਼ੱਕ, ਮੌਜੂਦ ਹਨ।

ਪਾਸਵਰਡ-ਰਹਿਤ ਪ੍ਰਮਾਣੀਕਰਨ, ਵਿਸ਼ੇਸ਼ ਅਧਿਕਾਰ ਪ੍ਰਾਪਤ ਪਹੁੰਚ ਦਾ ਪ੍ਰਬੰਧਨ, ਅਸਥਾਈ ਮਨਜ਼ੂਰੀਆਂ ਅਤੇ ਭਰੋਸੇਯੋਗ ਡਿਵਾਈਸਾਂ ਰਾਹੀਂ ਪੁਸ਼ਟੀ—ਇਹ ਸਾਰੇ ਤਰੀਕੇ ਜਾਣਕਾਰੀ ਸੁਰੱਖਿਆ ਦੇ ਖੇਤਰ ਵਿੱਚ ਲੰਮੇ ਸਮੇਂ ਤੋਂ ਜਾਣੇ ਜਾਂਦੇ ਹਨ।

ਇਹ ਤਰੀਕੇ Identity and Access Management, Privileged Access Management ਸਿਸਟਮਾਂ ਅਤੇ Zero Trust ਸੰਕਲਪਾਂ ਵਿੱਚ ਵਰਤੇ ਜਾਂਦੇ ਹਨ।

ਮੈਂ ਇਹ ਅਸੂਲ ਖੋਜਣ ਦਾ ਦਾਅਵਾ ਨਹੀਂ ਕਰਦਾ।

ਮੇਰਾ ਕੰਮ ਕੁਝ ਹੋਰ ਸੀ।

ਮੈਨੂੰ ਇੱਕ ਆਪਣਾ, ਏਕੀਕ੍ਰਿਤ ਸਿਸਟਮ ਬਣਾਉਣਾ ਸੀ, ਜੋ DigiMeld ਦੇ ਢਾਂਚੇ ਦੀਆਂ ਖ਼ਾਸ ਸਮੱਸਿਆਵਾਂ ਹੱਲ ਕਰੇ ਅਤੇ ਕਈ ਸੁਤੰਤਰ ਪ੍ਰੋਜੈਕਟਾਂ ਦੀ ਪ੍ਰਸ਼ਾਸਕੀ ਪਹੁੰਚ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਨ ਦੇਵੇ।

ਨਤੀਜੇ ਵਜੋਂ, ਮੈਂ ਕਈ ਜਾਣੇ-ਪਛਾਣੇ ਤਰੀਕਿਆਂ ਨੂੰ ਆਪਣੀਆਂ ਲੋੜਾਂ ਮੁਤਾਬਕ ਇੱਕ ਆਰਕੀਟੈਕਚਰ ਵਿੱਚ ਜੋੜਿਆ।

ਮੇਰਾ ਮੰਨਣਾ ਹੈ ਕਿ ਇੰਜੀਨੀਅਰਿੰਗ ਦੇ ਕੰਮ ਦੀ ਅਹਿਮੀਅਤ ਲਾਜ਼ਮੀ ਤੌਰ ’ਤੇ ਕੋਈ ਬਿਲਕੁਲ ਨਵੀਂ ਤਕਨੀਕ ਖੋਜਣ ਵਿੱਚ ਨਹੀਂ ਹੁੰਦੀ।

ਕਈ ਵਾਰ ਅਹਿਮੀਅਤ ਸਮੱਸਿਆ ਨੂੰ ਸਹੀ ਤਰ੍ਹਾਂ ਪਰਿਭਾਸ਼ਿਤ ਕਰਨ ਅਤੇ ਉਸਦਾ ਢੁੱਕਵਾਂ ਹੱਲ ਲੱਭਣ ਵਿੱਚ ਹੁੰਦੀ ਹੈ।

MeldID ਸਿਰਫ਼ ਪ੍ਰਸ਼ਾਸਕੀ ਪੈਨਲਾਂ ਲਈ ਨਹੀਂ ਹੈ

ਇੱਥੇ ਇੱਕ ਗੱਲ ਵੱਖਰੇ ਤੌਰ ’ਤੇ ਸਪਸ਼ਟ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ।

MeldID ਨੂੰ ਸਿਰਫ਼ ਮੇਰੀ ਆਪਣੀ ਪ੍ਰਸ਼ਾਸਕੀ ਪਹੁੰਚ ਲਈ ਬਣਾਇਆ ਗਿਆ ਸਾਧਨ ਨਹੀਂ ਸੀ।

ਇਹ ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਆਪਣੇ ਐਪਲੀਕੇਸ਼ਨਾਂ ਵਿੱਚ ਪਛਾਣ ਅਤੇ ਲੌਗਇਨ ਪੁਸ਼ਟੀ ਦੀਆਂ ਵਿਧੀਆਂ ਜੋੜਨ ਲਈ SDK ਵੀ ਦਿੰਦਾ ਹੈ।

ਇਹ SDK ਮੁਫ਼ਤ ਉਪਲਬਧ ਹੈ।

ਮਿਸਾਲ ਵਜੋਂ, ਕੋਈ ਬਾਹਰੀ ਡਿਵੈਲਪਰ MeldID ਨੂੰ ਯੂਜ਼ਰ ਪ੍ਰਮਾਣੀਕਰਨ ਦੀ ਪੁਸ਼ਟੀ ਲਈ ਇੱਕ ਵਾਧੂ ਪਰਤ ਵਜੋਂ ਵਰਤ ਸਕਦਾ ਹੈ।

ਭਾਵੇਂ ਐਪਲੀਕੇਸ਼ਨ ਵਿੱਚ ਯੂਜ਼ਰਨੇਮ ਅਤੇ ਪਾਸਵਰਡ ਰਾਹੀਂ ਰਵਾਇਤੀ ਲੌਗਇਨ ਕਾਇਮ ਰਹੇ, ਪਰ ਸਹੀ ਵੇਰਵੇ ਭਰਨਾ ਪ੍ਰਮਾਣੀਕਰਨ ਪੂਰਾ ਕਰਨ ਲਈ ਕਾਫ਼ੀ ਨਾ ਹੋਵੇ।

ਯੂਜ਼ਰ ਦੀ ਭਰੋਸੇਯੋਗ ਮੋਬਾਈਲ ਡਿਵਾਈਸ ’ਤੇ ਬੇਨਤੀ ਆਉਂਦੀ ਹੈ, ਜਿੱਥੇ ਉਹ ਲੌਗਇਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਨੂੰ ਮਨਜ਼ੂਰ ਜਾਂ ਰੱਦ ਕਰ ਸਕਦਾ ਹੈ।

ਇਸ ਨਾਲ ਖਾਤਾ-ਵੇਰਵਿਆਂ ਦੇ ਹੱਥ ਲੱਗ ਜਾਣ ’ਤੇ ਬਿਨਾਂ ਇਜਾਜ਼ਤ ਪਹੁੰਚ ਦੇ ਖ਼ਤਰੇ ਨੂੰ ਘਟਾਇਆ ਜਾ ਸਕਦਾ ਹੈ।

MeldID ਦੀ ਇਸ ਆਮ ਤੌਰ ’ਤੇ ਉਪਲਬਧ ਸਹੂਲਤ ਅਤੇ DigiMeld ਪ੍ਰੋਜੈਕਟਾਂ ਲਈ ਮੇਰੇ ਬਣਾਏ ਪ੍ਰਸ਼ਾਸਕੀ ਪਹੁੰਚ ਮਾਡਲ ਵਿਚਕਾਰ ਫ਼ਰਕ ਸਮਝਣਾ ਜ਼ਰੂਰੀ ਹੈ।

ਦੋਵੇਂ ਭਰੋਸੇ ਅਤੇ ਕਾਰਵਾਈਆਂ ਦੀ ਪੁਸ਼ਟੀ ਦੇ ਸਾਂਝੇ ਅਸੂਲ ਵਰਤਦੇ ਹਨ, ਪਰ ਉਹਨਾਂ ਦੇ ਕੰਮ ਵੱਖਰੇ ਹਨ।

ਸੁਰੱਖਿਆ ਸਿਰਫ਼ ਮੌਜੂਦਾ ਚੀਜ਼ ਦੀ ਰੱਖਿਆ ਕਰਨਾ ਨਹੀਂ

ਇਸ ਸਿਸਟਮ ’ਤੇ ਕੰਮ ਕਰਨ ਨਾਲ ਮੈਨੂੰ ਪ੍ਰਮਾਣੀਕਰਨ ਦੇ ਰਵਾਇਤੀ ਤਰੀਕਿਆਂ ਨੂੰ ਵੱਖਰੇ ਨਜ਼ਰੀਏ ਨਾਲ ਦੇਖਣ ਲਈ ਮਜਬੂਰ ਕੀਤਾ।

ਅਸੀਂ ਅਕਸਰ ਉਸ ਚੀਜ਼ ਦੀ ਰੱਖਿਆ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਾਂ ਜੋ ਇਤਿਹਾਸਕ ਕਾਰਨਾਂ ਕਰਕੇ ਮੌਜੂਦ ਹੈ।

ਨਵੀਆਂ ਜਾਂਚਾਂ, ਪਾਬੰਦੀਆਂ, ਵਾਧੂ ਪਾਸਵਰਡ ਅਤੇ ਸੁਰੱਖਿਆ ਦੀਆਂ ਹੋਰ ਪਰਤਾਂ ਜੋੜਦੇ ਹਾਂ।

ਕਈ ਵਾਰ ਇਹ ਸੱਚਮੁੱਚ ਜ਼ਰੂਰੀ ਹੁੰਦਾ ਹੈ।

ਪਰ ਕਈ ਵਾਰ ਕੋਈ ਹੋਰ ਸਵਾਲ ਪੁੱਛਣਾ ਵਧੇਰੇ ਲਾਭਦਾਇਕ ਹੁੰਦਾ ਹੈ:

ਕੀ ਜਿਸ ਵਿਧੀ ਦੀ ਅਸੀਂ ਰੱਖਿਆ ਕਰ ਰਹੇ ਹਾਂ, ਉਸਦਾ ਪੁਰਾਣੇ ਰੂਪ ਵਿੱਚ ਮੌਜੂਦ ਰਹਿਣਾ ਲਾਜ਼ਮੀ ਹੈ?

ਮੇਰੇ ਮਾਮਲੇ ਵਿੱਚ ਜਵਾਬ ਸੀ—ਨਹੀਂ।

ਮੈਨੂੰ ਅਜਿਹੇ ਪ੍ਰਸ਼ਾਸਕੀ ਲੌਗਇਨ ਫਾਰਮ ਦੀ ਲੋੜ ਨਹੀਂ ਸੀ ਜੋ ਹਰ ਵੇਲੇ ਉਪਲਬਧ ਰਹੇ।

ਮੈਨੂੰ ਲੋੜ ਸੀ ਕਿ ਜਦੋਂ ਲੋੜ ਪਵੇ, ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਪ੍ਰਸ਼ਾਸਕੀ ਅਧਿਕਾਰ ਹਾਸਲ ਕਰ ਸਕਾਂ।

ਇਹ ਦੋ ਵੱਖਰੇ ਕੰਮ ਹਨ।

ਪਹਿਲੇ ਤੋਂ ਦੂਜੇ ਵੱਲ ਜਾਣ ਨਾਲ ਨਾ ਸਿਰਫ਼ ਤਕਨੀਕੀ ਆਰਕੀਟੈਕਚਰ ਬਦਲਿਆ, ਸਗੋਂ ਪ੍ਰੋਜੈਕਟਾਂ ਨਾਲ ਰੋਜ਼ਾਨਾ ਕੰਮ ਕਰਨ ਦਾ ਤਰੀਕਾ ਵੀ ਬਦਲ ਗਿਆ।

ਅੰਤਿਮ ਮੰਜ਼ਿਲ ਨਹੀਂ, ਸਗੋਂ ਚੁਣੀ ਹੋਈ ਦਿਸ਼ਾ

ਅੱਜ ਇਹ ਆਰਕੀਟੈਕਚਰ DigiMeld ਈਕੋਸਿਸਟਮ ਦੇ ਵੱਡੇ ਹਿੱਸੇ ਵਿੱਚ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ।

ਬਾਕੀ ਪ੍ਰੋਜੈਕਟਾਂ ਨੂੰ ਹੌਲੀ-ਹੌਲੀ ਨਵੇਂ ਪ੍ਰਸ਼ਾਸਕੀ ਪਹੁੰਚ ਮਾਡਲ ’ਤੇ ਲਿਆਂਦਾ ਜਾ ਰਿਹਾ ਹੈ।

ਮੈਂ ਹਰ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਕੰਮ ਦੀ ਜਾਂਚ ਕਰਦਿਆਂ, ਪੜਾਅ-ਦਰ-ਪੜਾਅ ਮਾਈਗ੍ਰੇਸ਼ਨ ਕਰ ਰਿਹਾ ਹਾਂ। ਤਬਦੀਲੀ ਪੂਰੀ ਹੋਣ ਤੋਂ ਬਾਅਦ, ਮੈਂ ਪੂਰੇ ਸਿਸਟਮ ਦਾ ਵਾਧੂ ਆਡਿਟ ਕਰਨ ਦੀ ਯੋਜਨਾ ਬਣਾ ਰਿਹਾ ਹਾਂ।

ਇੰਟਰਫੇਸ ਦੇ ਕੁਝ ਹਿੱਸੇ ਅਤੇ ਸੈਸ਼ਨ ਪ੍ਰਬੰਧਨ ਦੇ ਨਿਯਮ ਅਜੇ ਵੀ ਬਦਲ ਸਕਦੇ ਹਨ।

ਪਰ ਮੂਲ ਵਿਚਾਰ ਤੈਅ ਹੋ ਚੁੱਕਾ ਹੈ।

ਮੈਂ ਉਸ ਮਾਡਲ ਵੱਲ ਵਾਪਸ ਨਹੀਂ ਜਾਣਾ ਚਾਹੁੰਦਾ ਜਿਸ ਵਿੱਚ ਆਪਣੇ ਦਰਜਨਾਂ ਪ੍ਰੋਜੈਕਟਾਂ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਨ ਲਈ ਮੈਨੂੰ ਦਰਜਨਾਂ ਪ੍ਰਸ਼ਾਸਕੀ ਪਾਸਵਰਡ ਲਗਾਤਾਰ ਸੰਭਾਲਣ ਅਤੇ ਵਰਤਣੇ ਪੈਣ।

ਇਸ ਦੇ ਨਾਲ ਹੀ, ਮੈਂ ਆਪਣੇ ਬਣਾਏ ਹੱਲ ਨੂੰ ਹਰ ਕਿਸੇ ਲਈ ਸਰਬਵਿਆਪੀ ਨਹੀਂ ਮੰਨਦਾ।

ਵੱਖ-ਵੱਖ ਸੰਸਥਾਵਾਂ ਦੀਆਂ ਲੋੜਾਂ, ਢਾਂਚੇ, ਖ਼ਤਰਿਆਂ ਦੇ ਮਾਡਲ ਅਤੇ ਪ੍ਰਸ਼ਾਸਨ ਦੇ ਤਰੀਕੇ ਵੱਖਰੇ ਹੁੰਦੇ ਹਨ।

ਜੋ DigiMeld ਈਕੋਸਿਸਟਮ ਲਈ ਸੁਵਿਧਾਜਨਕ ਅਤੇ ਵਾਜਬ ਹੈ, ਲਾਜ਼ਮੀ ਨਹੀਂ ਕਿ ਕਿਸੇ ਹੋਰ ਡਿਵੈਲਪਰ ਲਈ ਵੀ ਸਭ ਤੋਂ ਵਧੀਆ ਹੋਵੇ।

ਫਿਰ ਵੀ, ਅਧਿਕਾਰ ਅਸਥਾਈ ਤੌਰ ’ਤੇ ਦੇਣ ਦਾ ਅਸੂਲ ਧਿਆਨ ਦੇਣ ਯੋਗ ਹੈ।

ਅੰਤ ਵਿੱਚ

ਮੈਂ ਇਹ ਤਜਰਬਾ ਇਸ ਲਈ ਸਾਂਝਾ ਕਰਨ ਦਾ ਫ਼ੈਸਲਾ ਨਹੀਂ ਕੀਤਾ ਕਿ ਮੈਂ ਆਪਣੇ ਆਪ ਨੂੰ ਪ੍ਰਮਾਣੀਕਰਨ ਦੇ ਨਵੇਂ ਤਰੀਕੇ ਦਾ ਖੋਜੀ ਮੰਨਦਾ ਹਾਂ।

ਨਾ ਹੀ ਇਸ ਲਈ ਕਿ ਮੈਂ ਕਿਸੇ ਹੋਰ ਸਿਸਟਮ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਸੁਰੱਖਿਅਤ ਦੱਸਣਾ ਚਾਹੁੰਦਾ ਹਾਂ।

ਪੂਰੀ ਸੁਰੱਖਿਆ ਜਿਹੀ ਕੋਈ ਚੀਜ਼ ਨਹੀਂ ਹੁੰਦੀ।

ਮੈਨੂੰ ਸਿਰਫ਼ ਸਵਾਲ ਨੂੰ ਦੇਖਣ ਦਾ ਇਹ ਤਰੀਕਾ ਦਿਲਚਸਪ ਲੱਗਦਾ ਹੈ।

ਲਗਾਤਾਰ ਮੌਜੂਦ ਪ੍ਰਸ਼ਾਸਕੀ ਲੌਗਇਨ ਦੀ ਬੇਅੰਤ ਰੱਖਿਆ ਕਰਨ ਦੀ ਬਜਾਏ, ਅਸੀਂ ਉਸਦੀ ਲੋੜ ’ਤੇ ਮੁੜ ਵਿਚਾਰ ਕਰ ਸਕਦੇ ਹਾਂ।

ਬਹੁਤ ਸਾਰੇ ਪਾਸਵਰਡ ਸੰਭਾਲਣ ਦੀ ਬਜਾਏ, ਅਸਥਾਈ ਮਨਜ਼ੂਰੀਆਂ ਵਰਤ ਸਕਦੇ ਹਾਂ।

ਪਹਿਲੇ ਪ੍ਰਮਾਣੀਕਰਨ ਤੋਂ ਬਾਅਦ ਆਪਣੇ ਆਪ ਭਰੋਸਾ ਕਰਨ ਦੀ ਬਜਾਏ, ਖ਼ਾਸ ਅਧਿਕਾਰ ਦੇਣ ਦੀ ਪੁਸ਼ਟੀ ਕਰ ਸਕਦੇ ਹਾਂ।

ਸੈਸ਼ਨ ਖ਼ਤਮ ਹੋਣ ਦੀ ਉਡੀਕ ਕਰਨ ਦੀ ਬਜਾਏ, ਪਹੁੰਚ ਨੂੰ ਕੇਂਦਰੀ ਤੌਰ ’ਤੇ ਰੱਦ ਕਰਨ ਦੀ ਵਿਵਸਥਾ ਕਰ ਸਕਦੇ ਹਾਂ।

ਅਤੇ ਅਖ਼ੀਰ ਵਿੱਚ, ਹਰ ਪ੍ਰੋਜੈਕਟ ਲਈ ਵੱਖਰਾ ਲੌਗਇਨ ਤਰੀਕਾ ਬਣਾਉਣ ਦੀ ਬਜਾਏ, ਐਪਲੀਕੇਸ਼ਨਾਂ ਦੀ ਸੁਤੰਤਰਤਾ ਕਾਇਮ ਰੱਖਦਿਆਂ ਪ੍ਰਸ਼ਾਸਕੀ ਪਹੁੰਚ ਪ੍ਰਬੰਧਨ ਦਾ ਇੱਕ ਸਾਂਝਾ ਸਿਸਟਮ ਬਣਾ ਸਕਦੇ ਹਾਂ।

ਮੈਂ ਇਹ ਦਾਅਵਾ ਨਹੀਂ ਕਰਦਾ ਕਿ ਇਸ ਤਰੀਕੇ ਨਾਲ ਕਿਸੇ ਵੀ ਤਰ੍ਹਾਂ ਦੀ ਸੁਰੱਖਿਆ-ਭੰਗ ਦੀ ਸੰਭਾਵਨਾ ਖ਼ਤਮ ਹੋ ਜਾਂਦੀ ਹੈ।

ਇਹ ਸਿਰਫ਼ ਧਿਆਨ ਨੂੰ ਲਗਾਤਾਰ ਮੌਜੂਦ ਖਾਤਾ-ਵੇਰਵਿਆਂ ਦੀ ਰੱਖਿਆ ਤੋਂ ਹਟਾ ਕੇ ਅਧਿਕਾਰਾਂ ਨੂੰ ਨਿਯੰਤਰਿਤ ਢੰਗ ਨਾਲ ਦੇਣ ਅਤੇ ਖ਼ਤਮ ਕਰਨ ਵੱਲ ਲੈ ਜਾਂਦਾ ਹੈ।

ਸ਼ਾਇਦ ਕਈ ਵਾਰ ਹਮਲੇ ਦੀ ਸੰਭਾਵਨਾ ਵਾਲੀ ਸਤ੍ਹਾ ਘਟਾਉਣ ਦਾ ਸਭ ਤੋਂ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਤਰੀਕਾ ਇੱਕ ਹੋਰ ਸੁਰੱਖਿਆ ਵਿਧੀ ਜੋੜਨਾ ਨਹੀਂ, ਸਗੋਂ ਉਸ ਚੀਜ਼ ਨੂੰ ਛੱਡ ਦੇਣਾ ਹੁੰਦਾ ਹੈ ਜਿਸ ਤੋਂ ਬਿਨਾਂ ਵੀ ਸਿਸਟਮ ਚੱਲ ਸਕਦਾ ਹੈ।

MeldID Admin Gateway ਦੀ ਕਹਾਣੀ ਮੇਰੇ ਲਈ ਇਸੇ ਵਿਚਾਰ ਨਾਲ ਸ਼ੁਰੂ ਹੋਈ।