ਥੀਓ ਦੇ ਰਾਟਡ, OpenBSD ਅਤੇ ਡਿਫੌਲਟ-ਤੌਰ 'ਤੇ ਸੁਰੱਖਿਅਤ ਸੋਚ

"ਡਿਫੌਲਟ-ਤੌਰ ਤੇ ਸੁਰੱਖਿਅਤ" ਦਾ ਅਰਥ ਅਮਲ ਵਿੱਚ\n\n"ਡਿਫੌਲਟ-ਤੌਰ ਤੇ ਸੁਰੱਖਿਅਤ" ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਇਕ ਸਿਸਟਮ ਆਪਣੀ ਸਭ ਤੋਂ ਸੁਰੱਖਿਅਤ ਵਾਜਬ ਸਥਿਤੀ ਤੋਂ ਸ਼ੁਰੂ ਹੋਵੇ ਬਿਨਾਂ ਤੁਹਾਨੂੰ ਮੈਨੂਜ਼ੀ, ਲੰਬੀ ਚੈੱਕਲਿਸਟ ਪੜ੍ਹਣ ਜਾਂ ਪਹਿਲਾਂ ਹੀ ਪਤਾ ਹੋਣ ਕਿ ਕੀ ਗਲਤ ਹੋ ਸਕਦਾ ਹੈ। ਪਹਿਲੀ ਇੰਸਟਾਲ ਉਹ ਸੇਵਾਵਾਂ ਘੱਟ ਤੋਂ ਘੱਟ ਖੁਲ੍ਹੀਆਂ ਰੱਖਣੀ ਚਾਹੀਦੀ ਹੈ, ਅਧਿਕਾਰ ਸੀਮਿਤ ਕਰਨੇ ਚਾਹੀਦੇ ਹਨ, ਅਤੇ ਸੁਰੱਖਿਅਤ ਵਿਕਲਪਾਂ ਆਪਣੇ ਆਪ ਚੁਣੇ ਜਾਣੇ ਚਾਹੀਦੇ ਹਨ। ਤੁਸੀਂ ਫਿਰ ਵੀ ਚੀਜ਼ਾਂ ਖੋਲ ਸਕਦੇ ਹੋ—ਪਰ ਇਹ ਸੂਚਨਾ-ਪੂਰਨ ਅਤੇ ਇਰਾਦੇ ਨਾਲ ਕੀਤਾ ਜਾਵੇ।\n\n### ਡਿਫੌਲਟ ਇੱਕ ਚੈਕਬਾਕਸ ਨਹੀਂ, ਫੈਸਲਾ ਹਨ\n\nਡਿਫੌਲਟ ਉਹ ਰਾਹ ਹੈ ਜੋ ਬਹੁਤ ਸਾਰੇ ਲੋਕ ਲੈਂਦੇ ਹਨ। ਇਸ ਕਰਕੇ ਇਹ ਇੱਕ ਸੁਰੱਖਿਆ ਨਿਯੰਤਰਣ ਬਣ ਜਾਂਦਾ ਹੈ: ਇਹ ਅਸਲ-ਦੁਨੀਆ ਦੇ ਨਤੀਜਿਆਂ ਨੂੰ ਕਿਸੇ ਵੀ ਆਪਸ਼ਨਲ ਹਾਰਡਨਿੰਗ ਗਾਈਡ ਨਾਲੋਂ ਜ਼ਿਆਦਾ ਪ੍ਰਭਾਵਿਤ ਕਰਦਾ ਹੈ। ਜੇ ਡਿਫੌਲਟ ਕੰਫਿਗਰੇਸ਼ਨ ਖਾਮੋਸ਼ੀ ਨਾਲ ਵਧੀਆ ਨੈੱਟਵਰਕ ਸੇਵਾਵਾਂ, ਢੀਲੇ ਫਾਇਲ ਪਹੁੰਚ ਜਾਂ ਜੋਖਿਮ ਭਰਿਆ ਫੀਚਰ ਐਨੇਬਲ ਕਰਦਾ ਹੈ, ਤਾਂ ਬਹੁਤ ਸਾਰੀਆਂ ਡਿਪਲੋਇਮੈਂਟ ਲੰਮੇ ਸਮੇਂ ਤੱਕ ਉਹ ਖਤਰਾ ਵਹਿੱਕੇ ਬਹਾਲ ਰੱਖਣਗੇ।\n\nOpenBSD ਨੂੰ ਸੁਰੱਖਿਆ ਚਰਚਾਵਾਂ ਵਿੱਚ ਅਕਸਰ ਉਦਾਹਰਣ ਵਜੋਂ ਲਿਆ ਜਾਂਦਾ ਹੈ ਕਿਉਂਕਿ ਇਹ ਦਹਾਕਿਆਂ ਤੋਂ ਇਸ ਵਿਚਾਰ ਨੂੰ ਇੱਕ ਮੁੱਖ ਇੰਜੀਨੀਅਰਿੰਗ ਲਕਸ਼ ਵਜੋਂ ਲੈਂਦਾ ਆ ਰਿਹਾ ਹੈ: ਰੱਖ-ਰਖਾਵ ਵਾਲੇ ਡਿਫੌਲਟ ਭੇਜੋ, ਹਮਲਾ ਸਤਹ ਘਟਾਓ, ਅਤੇ ਜੋਖਿਮ ਭਰਿਆ ਵਿਵਹਾਰ opt-in ਬਣਾਓ। ਇਹ ਫੋਕਸ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ, ਨੈੱਟਵਰਕ ਸੇਵਾਵਾਂ ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ ਡਿਜ਼ਾਈਨ ਬਾਰੇ ਬਹੁਤ ਸਾਰੇ ਇੰਜੀਨੀਅਰਾਂ ਦੀ ਸੋਚ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰ ਚੁੱਕੀ ਹੈ।\n\n### ਇਸ ਲੇਖ ਵਿੱਚ ਕੀ ਉਮੀਦ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ\n\nਅਸੀਂ ਉਹ ਅਭਿਆਸ ਵੇਖਾਂਗੇ ਜੋ "ਡਿਫੌਲਟ-ਤੌਰ ਤੇ ਸੁਰੱਖਿਅਤ" ਮਨੋਵਿਗਿਆਨ ਨੂੰ ਸਹਾਇਤਾ ਦੇਂਦੇ ਹਨ, ਜਿੰਨ੍ਹਾਂ ਵਿੱਚ ਸ਼ਾਮਲ ਹਨ:\n\n- ਡਿਫੌਲਟ ਜੋ ਨੁਕਸਾਨ ਘਟਾਉਂਦੇ ਹਨ (ਘੱਟ ਸੇਵਾਵਾਂ ਸੁਣ ਰਹੀਆਂ, ਵਧੇਰੇ ਸਕਿੰਟ ਅਧਿਕਾਰ).\n- ਆਡੀਟਿੰਗ ਦੀ ਸੰਸਕ੍ਰਿਤੀ ("ਕੋਡ ਪੜ੍ਹੋ" ਹਰ ਰੋਜ਼ ਦੀ ਆਦਤ)।\n- ਇਕਸਪਲੋਇਟ ਮਿਟੀਗੇਸ਼ਨ ਜੋ ਆਮ ਹਮਲਿਆਂ ਦੀ ਕੀਮਤ ਵਧਾਉਂਦੇ ਹਨ।\n- ਪ੍ਰਕਿਰਿਆ ਅਤੇ ਸੰਸਕ੍ਰਿਤੀ—ਮਾਨਕ, ਸਮੀਖਿਆਵਾਂ, ਅਤੇ ਕਈ ਵਾਰੀ ਉਸ ਤੀਖੇਵਾਲੇ ਫੈਸਲੇ ਜੋ ਗੁਣਵੱਤਾ ਨੂੰ ਧੱਕਾ ਦਿੰਦੇ ਹਨ।\n\n### ਨੀਤੀਆਂ ਬਜਾਏ ਸ਼ਖਸੀਅਤਾਂ\n\nਥੀਓ ਦੇ ਰਾਟਡ ਦੀ ਭੂਮਿਕਾ ਇਤਿਹਾਸਕ ਢੰਗ ਨਾਲ ਮਹੱਤਵਪੂਰਨ ਹੈ, ਪਰ ਇਥੇ ਲਕਸ਼ ਹੀ ਹੀਰੋ ਪੂਜਾ ਨਹੀਂ। ਸਭ ਤੋਂ ਉਪਯੋਗੀ ਸਿੱਖਣ ਵਾਲੀ ਗੱਲ ਇਹ ਹੈ ਕਿ ਕਿਸ ਤਰ੍ਹਾਂ ਕੋਈ ਪ੍ਰੋਜੈਕਟ ਸੁਰੱਖਿਆ ਨੂੰ ਇੱਕ ਪਿੱਛੇ ਛੱਡੀ ਚੀਜ਼ ਤੋਂ ਦੁਹਰਾਏ ਜਾਣ ਯੋਗ ਨੇੜਿਆਂ ਵਿੱਚ ਬਦਲ ਸਕਦਾ ਹੈ—ਉਹ ਚੋਣਾਂ ਜੋ ਡਿਫੌਲਟਸ, ਕੋਡ ਰਿਵਿਊ ਆਦਤਾਂ ਅਤੇ ਸੁਵਿਧਾ ਨੂੰ "ਨਾ" ਕਹਿਣ ਦੀ ਤਿਆਰੀ ਵਿੱਚ ਦਿਖਾਈ ਦਿੰਦੀਆਂ ਹਨ।\n\n## ਥੀਓ ਦੇ ਰਾਟਡ ਅਤੇ OpenBSD ਦਾ ਉਦਗਮ\n\nਥੀਓ ਦੇ ਰਾਟਡ ਇੱਕ ਕੈਨੇਡੀਅਨ ਡਿਵੈਲਪਰ ਹਨ ਜੋ BSD ਪਰਿਵਾਰ ਵਿੱਚ ਧਿਆਨ-ਕੇਂਦ੍ਰਿਤ ਸਿਸਟਮ ਇੰਜੀਨੀਅਰਿੰਗ ਲਈ ਜਾਣੇ ਜਾਂਦੇ ਹਨ। OpenBSD ਤੋਂ ਪਹਿਲਾਂ, ਉਹ ਬੀਐਸਡੀ-অন-ਪੀਸੀ ਕੋਸ਼ਿਸ਼ਾਂ ਵਿੱਚ ਕੇਂਦਰੀ ਹਿੱਸੇਦਾਰ ਸਨ ਅਤੇ 1990ਾਂ ਦੇ ਸ਼ੁਰੂ ਵਿੱਚ NetBSD ਦੇ ਕੋ-ਫਾਊਂਡਰਾਂ ਵਿੱਚੋਂ ਇੱਕ ਬਣੇ। ਇਹ ਪਿਛੋਕੜ ਮਾਇਨੇ ਰੱਖਦੀ ਹੈ: BSDs ਕੋਈ "ਐਪ" ਨਹੀਂ ਸਨ, ਇਹ ਭਰੋਸੇਯੋਗ ਨਿਰਮਾਣ ਲਈ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਸਨ।\n\n### OpenBSD ਕਿਉਂ ਬਣਿਆ\n\nOpenBSD 1995 ਵਿੱਚ ਸ਼ੁਰੂ ਹੋਇਆ ਜਦੋਂ de Raadt ਨੇ NetBSD ਪ੍ਰੋਜੈਕਟ ਛੱਡਿਆ। ਨਵਾਂ ਪ੍ਰੋਜੈਕਟ ਨਵੀਂ ਚੀਜ਼ਾਂ ਦੀ ਪਾਲਣਾ ਕਰਨ ਜਾਂ "ਸਭ ਕੁਝ ਵਾਲਾ BSD" ਬਣਾਉਣ ਲਈ ਨਹੀਂ ਸੀ। ਇਹ ਇਸ ਲਈ ਸ਼ੁਰੂ ਕੀਤਾ ਗਿਆ ਕਿ ਇੱਕ ਐਸਾ ਸਿਸਟਮ ਬਣਾਇਆ ਜਾਵੇ ਜਿੱਥੇ ਸੱਠ-ਸਹੀਪਨ ਅਤੇ ਸੁਰੱਖਿਆ ਖੁੱਲ੍ਹ ਕੇ ਮਹੱਤਵ ਰੱਖਣ—ਭਾਵੇਂ ਇਸਦਾ ਮਤਲਬ ਆਸਾਨੀ ਨੂੰ ਮਨਾਹੀ ਕਰਨਾ ਹੋਵੇ।\n\nਸ਼ੁਰੂ ਤੋਂ, OpenBSD ਨੇ ਉਹਨਾਂ ਚੀਜ਼ਾਂ ਵਿੱਚ ਊਰਜਾ ਲਾਈ ਜਿਨ੍ਹਾਂ ਨੂੰ ਬਹੁਤ ਸਾਰੇ ਪ੍ਰੋਜੈਕਟ ਅਣਗਲੋਂ ਸਮਝਦੇ ਹਨ:\n\n- ਅਸੁਰੱਖਿਅਤ ਪੈਟਰਨ ਅਤੇ ਸੁਖੜ ਬੱਗਾਂ ਲਈ ਕੋਡ ਆਡੀਟ ਕਰਨਾ\n- ਡਿਫੌਲਟਸ ਤੰਗ ਕਰਨਾ ਤਾਂ ਜੋ ਤਾਜ਼ਾ ਇੰਸਟਾਲ ਗਲਤ ਕੰਫਿਗਰ ਕਰਨਾ ਔਖਾ ਹੋਵੇ\n- ਉਹ ਫੀਚਰ ਡਿਜ਼ਾਈਨ ਕਰਨਾ ਜੋ ਸਮੇਂ ਨਾਲ ਵਿੱਚ ਰਿਵਿਊ ਅਤੇ ਰੱਖਿਆ ਕਿੱਤੀ ਜਾ ਸਕਣ\n\n### "ਫੀਚਰ ਪਹਿਲਾਂ" ਦੇ ਮਕਸਦ ਤੋਂ ਵੱਖਰਾ ਲਕਸ਼\n\nਕਈ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਅਤੇ ਡਿਸਟ੍ਰੋ ਫੈਲ ਵਿੱਚ ਮੁਕਾਬਲਾ ਕਰਦੇ ਹਨ: ਹੋਰ ਡਰਾਈਵਰ, ਹੋਰ ਬੰਡਲ ਕੀਤੀਆਂ ਸੇਵਾਵਾਂ, ਜ਼ਿਆਦਾ ਵਿਵਿਧ ਵਿਕਲਪ। ਇਹ جائز ਮਕਸਦ ਹਨ ਅਤੇ ਯੂਜ਼ਰਾਂ ਦੀ ਮਦਦ ਕਰਦੇ ਹਨ।\n\nOpenBSD ਦੀ ਮੂਲ ਕਹਾਣੀ ਇੱਕ ਵੱਖਰੀ ਸ਼ਰਤ ਦਿਖਾਉਂਦੀ: कि ਇੱਕ ਛੋਟਾ, ਸਮਝਣਯੋਗ ਬੇਸ ਸਿਸਟਮ—ਸੰਰੱਖਿਤ ਡਿਫੌਲਟਸ ਨਾਲ ਭੇਜਿਆ ਗਿਆ—ਸੁਰੱਖਿਆ-ਗੰਭੀਰ ਗਲਤੀਆਂ ਦੀ ਸੰਭਾਵਨਾ ਘਟਾ ਸਕਦਾ ਹੈ।\n\nਇਸਦਾ ਮਤਲਬ ਇਹ ਨਹੀਂ ਕਿ ਹੋਰ ਪਹੁੰਚੇ ਗਲਤ ਹਨ; ਪਰ ਯਹ ਫੈਸਲੇ ਰੋਜ਼ਾਨਾ ਦੀਆਂ ਚੋਣਾਂ ਵਿੱਚ ਵਾਕਫ਼ ਹੋ ਜਾਂਦੇ ਹਨ: ਕਿਸੇ ਸਰਵਿਸ ਨੂੰ ਡਿਫੌਲਟ 'ਤੇ ਐਨੇਬਲ ਕਰਨਾ, ਇਕ ਜਟਿਲ ਨਵੇਂ ਸਬ-ਸਿਸਟਮ ਨੂੰ ਸਵੀਕਾਰ ਕਰਨਾ, ਜਾਂ ਇੱਕ ਇੰਟਰਫੇਸ ਨੂੰ ਦੁਬਾਰਾ ਡਿਜ਼ਾਈਨ ਕਰਨਾ ਤਾਂ ਜੋ ਇਸਦਾ ਗਲਤ ਉਪਯੋਗ ਮੁਸ਼ਕਲ ਹੋ ਜਾਵੇ।\n\n### ਸੁਰੱਖਿਆ ਲਕਸ਼ਾਂ ਵਿਰੁੱਧ ਨਤੀਜਿਆਂ\n\nOpenBSD ਦਾ ਸਥਾਪਨਾ-ਜੋੜ ਸੁਰੱਖਿਆ ਨੂੰ ਇੱਕ ਲਕਸ਼ ਵਜੋਂ ਦੇਖਦਾ ਸੀ: ਸੁਰੱਖਿਆ ਨੂੰ ਇੱਕ ਡਿਜ਼ਾਈਨ ਪਾਬੰਦੀ ਸਮਝੋ, ਨਾ ਕਿ ਬਾਅਦ ਵਿੱਚ ਜੋੜੀ ਜਾਨ ਵਾਲੀ ਚੀਜ਼। ਪਰ ਲਕਸ਼ ਅਤੇ ਪ੍ਰਾਪਤੀ ਇਕੋ ਨਹੀਂ ਹੁੰਦੀਆਂ। ਅਸਲ ਸੁਰੱਖਿਆ ਸਾਲਾਂ ਵਿੱਚ ਮਾਪੀ ਜਾਂਦੀ ਹੈ—ਖੋਜੀਆਂ ਗਈਆਂ ਖਾਮੀਆਂ, ਕਿੰਨੀ ਤੁਰੰਤ ਠੀਕ ਕੀਤੀਆਂ ਗਈਆਂ, ਕਿਵੇਂ ਸੁਚਨਾ ਦਿੱਤੀ ਗਈ, ਅਤੇ ਪ੍ਰੋਜੈਕਟ ਨੇ ਗਲਤੀਆਂ ਤੋਂ ਕਿਵੇਂ ਸਿੱਖਿਆ।\n\nOpenBSD ਦੀ ਸੰਸਕ੍ਰਿਤੀ ਇਸ ਪਿਛੋਕੜ ਤੋਂ ਉঔਝੀ: ਸੋਚੋ ਕਿ ਸੋਫਟਵੇਅਰ ਫੇਲ ਹੋ ਸਕਦਾ ਹੈ, ਫਿਰ ਡਿਜ਼ਾਈਨ ਅਤੇ ਪ੍ਰਕਿਰਿਆ ਇੰਨੀ ਬਣਾਓ ਕਿ ਫੇਲ ਹੋਣ ਦੀ ਸੰਭਾਵਨਾ ਘੱਟ ਹੋਵੇ।\n\n## ਡਿਫੌਲਟ ਇੱਕ ਸੁਰੱਖਿਆ ਨਿਯੰਤਰਣ ਵਜੋਂ (ਕੇਵਲ ਇੱਕ ਸੈਟਿੰਗ ਨਹੀਂ)\n\nOpenBSD "ਡਿਫੌਲਟ ਇੰਸਟਾਲ" ਨੂੰ ਇੱਕ ਸੁਰੱਖਿਆ ਵਾਅਦੇ ਵਜੋਂ ਦੇਖਦਾ ਹੈ: ਇੱਕ ਤਾਜ਼ਾ ਸਿਸਟਮ ਨੂੰ ਉਹਨਾਂ ਚੀਜ਼ਾਂ ਬਿਨਾਂ ਕਾਫੀ ਸੁਰੱਖਿਅਤ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਜਦ ਤੱਕ ਤੁਸੀਂ ਕਿਸੇ ਟਿਯੂਨਿੰਗ ਗਾਈਡ ਨੂੰ ਨਾ ਪੜ੍ਹੋ, ਫਾਇਰਵਾਲ ਨਿਯਮ ਨਾ ਜੋੜੋ, ਜਾਂ ਓਬਸਕਿਊਰ ਕੰਫਿਗ ਫਾਈਲਾਂ ਵਿੱਚ ਖੋਜ ਨਾ ਕਰੋ। ਇਸ ਨੂੰ ਆਸਾਨੀ ਨਹੀਂ ਮਾਨਾ ਜਾਣਾ ਚਾਹੀਦਾ—ਇਹ ਇੱਕ ਸੁਰੱਖਿਆ ਨਿਯੰਤਰਣ ਹੈ।\n\nਜੇ ਜ਼ਿਆਦਾਤਰ ਮਸ਼ੀਨਾਂ ਆਪਣੇ ਡਿਫੌਲਟਸ ਦੇ ਨੇੜੇ ਰਹਿੰਦੀਆਂ ਹਨ (ਜਿਵੇਂ ਅਸਲ ਜ਼ਿੰਦਗੀ ਵਿੱਚ ਬਹੁਤਾਂ ਹੁੰਦੀਆਂ ਹਨ), ਤਾਂ ਡਿਫੌਲਟਸ ਉਹ ਥਾਂ ਹੁੰਦੇ ਹਨ ਜਿੱਥੇ ਜੋਖ਼ਮ ਰੋਕਿਆ ਜਾਂਦਾ ਹੈ ਜਾਂ ਖਾਮੋਸ਼ੀ ਨਾਲ ਵਧਾਇਆ ਜਾਂਦਾ ਹੈ।\n\n### ਵੱਧ ਟਿਯੂਨਿੰਗ ਦੇ ਬਿਨਾਂ ਸੁਰੱਖਿਅਤ\n\nਡਿਫੌਲਟ-ਤੌਰ ਤੇ ਸੁਰੱਖਿਅਤ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਮੰਨਦਾ ਹੈ ਕਿ ਨਵੇਂ ਐਡਮਿਨਾਂ ਤੋਂ ਗਲਤੀਆਂ ਹੋਣਗੀਆਂ, ਉਹ ਵਿਹਲੇ ਹੋ ਸਕਦੇ ਹਨ, ਜਾਂ ਪੁਰਾਣੀ ਸਲਾਹ-ਮਸ਼ਵਰਾ ਫਾਲੋ ਕਰਦੇ ਹੋ ਸਕਦੇ ਹਨ। ਇਸ ਲਈ ਸਿਸਟਮ ਇੱਕ ਬਚਾਅਯੋਗ ਬੇਸਲਾਈਨ ਤੋਂ ਸ਼ੁਰੂ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ: ਘੱਟ ਨੁਕਸਾਨ, ਪੇਸ਼ਗੋਇਯੋਗ ਵਿਹਾਰ, ਅਤੇ ਐਸੀਆਂ ਕਨਫਿਗਰੇਸ਼ਨ ਜੋ ਤੁਹਾਨੂੰ ਹੈਰਾਨ ਨਾ ਕਰਨ।\n\nਜਦੋਂ ਤੁਸੀਂ ਕੁਝ ਬਦਲਦੇ ਹੋ, ਤੁਹਾਨੂੰ ਉਹ ਦਿਲੋਂ ਕਿਉਂ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ—ਕਿਉਂਕਿ ਤੁਹਾਨੂੰ ਉਸ ਸੇਵਾ ਦੀ ਲੋੜ ਹੈ—ਨਾ ਕਿ ਇਹ ਕਿ ਬੇਸ ਸਿਸਟਮ "ਮਦਦਗਾਰ" ਤੌਰ 'ਤੇ ਇਸ ਨੂੰ ਐਨੇਬਲ ਕਰ ਗਿਆ।\n\n### ਰੱਖ-ਰਖਾਵ ਵਾਲੇ ਫੀਚਰ, ਘੱਟ ਸੇਵਾਵਾਂ\n\nਇਸ ਮਨੋਵਿਗਿਆਨ ਦੀ ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਪ੍ਰਗਟੀਕਰਨ ਸੰਵਿਹਿਤ ਫੀਚਰ ਚੋਣ ਅਤੇ ਘੱਟ ਨੈੱਟਵਰਕ-ਮੁਖੀ ਸੇਵਾਵਾਂ ਦੇ ਤਰਫ ਰੁਝਾਨ ਹੈ। ਹਰ ਇਕ ਸੁਣਨ ਵਾਲਾ ਡੇਮਨ ਨਵਾਂ ਥਾਂ ਹੈ ਜਿੱਥੇ ਬੱਗ, ਗਲਤ ਕੰਫਿਗਰੇਸ਼ਨ, ਅਤੇ ਭੁੱਲੇ ਹੋਏ ਕ੍ਰੈਡੇਨਸ਼ਿਅਲ ਛੁਪ ਸਕਦੇ ਹਨ।\n\nOpenBSD ਦੇ ਡਿਫੌਲਟ ਮੁੱਖ ਰੂਪ ਵਿੱਚ ਸ਼ੁਰੂਆਤੀ ਹਮਲਾ ਸਤਹ ਨੂੰ ਛੋਟਾ ਰੱਖਦੇ ਹਨ, ਤਾਂ ਜੋ ਪਹਿਲੀ ਸੁਰੱਖਿਆ ਫ਼ੈਤ हासिल ਹੋਵੇ: ਤੁਸੀਂ ਮੰਗਿਆ ਨਹੀਂ ਉਹ ਚਲਾਉਣਾ ਨਹੀਂ।\n\nਇਹ ਰੱਖ-ਰਖਾਵ ਉਹਨਾਂ "ਫੁੱਟ-ਗਨਜ਼" ਦੀ ਗਿਣਤੀ ਵੀ ਘਟਾਉਂਦਾ ਹੈ—ਉਹ ਫੀਚਰ ਜੋ ਤਾਕਤਵਰ ਹਨ ਪਰ ਸਿਖਣ ਸਮੇਂ ਆਸਾਨੀ ਨਾਲ ਗਲਤ ਵਰਤੇ ਜਾ ਸਕਦੇ ਹਨ।\n\n### ਕੰਟ੍ਰੋਲ ਵਜੋਂ ਡੌਕਯੂਮੈਂਟੇਸ਼ਨ\n\nਡਿਫੌਲਟ ਸਿਰਫ਼ ਤਦ ਹੀ ਮਦਦਗਾਰ ਹੁੰਦੇ ਹਨ ਜਦ ਲੋਕ ਉਹਨਾਂ ਨੂੰ ਸਮਝ ਸਕਣ ਅਤੇ ਰਖ ਸਕਣ। OpenBSD ਦੀ ਸੰਸਕ੍ਰਿਤੀ ਸਾਫ਼ ਦਸਤਾਵੇਜ਼ ਅਤੇ ਸਪੱਫ਼ ਕੰਫਿਗਰੇਸ਼ਨ ਫਾਈਲਾਂ 'ਤੇ ਜ਼ੋਰ ਦਿੰਦੀ ਹੈ ਤਾਂ ਜੋ ਐਡਮਿਨ ਤੇਜ਼ੀ ਨਾਲ ਬੁਨਿਆਦੀ ਸਵਾਲਾਂ ਦਾ ਉਤਰ ਲੱਭ ਸਕਣ:\n\n- ਕੀ ਚੱਲ ਰਿਹਾ ਹੈ?\n- ਇਹ ਕਿਉਂ ਚੱਲ ਰਿਹਾ ਹੈ?\n- ਇਹ ਕਿੱਥੇ ਕੰਫਿਗਰ ਕੀਤਾ ਗਿਆ ਹੈ?\n- ਇਸ ਨੂੰ ਬਦਲਣ ਦਾ ਸਭ ਤੋਂ ਸੁਰੱਖਿਅਤ ਢੰਗ ਕੀ ਹੈ?\n\nਇਹ ਸਪਸ਼ਟਤਾ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿਉਂਕਿ ਸੁਰੱਖਿਆ ਨਾਕਾਮੀਆਂ ਅਕਸਰ ਆਪਰੇਸ਼ਨਲ ਹੁੰਦੀਆਂ ਹਨ: ਇੱਕ ਸੇਵਾ ਜੋ ਅਣਜਾਣੇ ਤੌਰ 'ਤੇ ਚਲਦੀ ਰਹਿ ਗਈ, ਇੱਕ ਨਕਲ ਕੀਤਾ ਕੰਫਿਗ ਜਿਸ ਵਿੱਚ ਅਸੁਰੱਖਿਅਤ ਵਿਕਲਪ ਹਨ, ਜਾਂ ਧਾਰਨਾ ਕਿ "ਕਿਸੇ ਹੋਰ ਨੇ ਪਹਿਲਾਂ ਹੀ ਇਸ ਨੂੰ ਹਾਰਡਨ ਕੀਤਾ ਹੋਵੇਗਾ।"\n\nOpenBSD ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ ਕਿ ਸੁਰੱਖਿਅਤ ਰਾਹ ਅਸਾਨ, ਸਪਸ਼ਟ ਅਤੇ ਪਹਿਲੇ ਬੂਟ ਤੋਂ ਹੀ ਪ੍ਰਾਪਤਯੋਗ ਬਣੇ।\n\n## ਆਡੀਟਿੰਗ ਸੰਸਕ੍ਰਿਤੀ: "ਕੋਡ ਪੜ੍ਹੋ" ਅਤੇ ਵਿਵਸਥਿਤ ਸਮੀਖਿਆ\n\nOpenBSD ਦੀ ਸੁਰੱਖਿਆ ਖ੍ਯਾਤੀ ਸਿਰਫ਼ ਚਤੁਰ ਮਿਟੀਗੇਸ਼ਨਾਂ ਜਾਂ ਕਠੋਰ ਡਿਫੌਲਟਸ ਬਾਰੇ ਨਹੀਂ ਹੈ—ਇਹ ਇੱਕ ਆਦਤ ਬਾਰੇ ਵੀ ਹੈ: ਇਹ ਮੰਨਣਾ ਕਿ ਜਦ ਲੋਕ ਨਿਰੰਤਰ, ਇਰਾਦੇ ਨਾਲ ਕੋਡ ਪੜ੍ਹਦੇ ਅਤੇ ਸਵਾਲ ਚੁੱਕਦੇ ਹਨ ਤਾਂ ਸੁਰੱਖਿਆ ਸੁਧਰਦੀ ਹੈ।\n\n"ਕੋਡ ਪੜ੍ਹੋ" ਨਾਂ ਵਰਤੀਆਂ ਹੋਈ ਨਾਰ ਇਹੋ ਜਿਹੀ ਸਲੋਗਨ ਨਹੀਂ, ਸਗੋਂ ਇੱਕ ਵਰਕਫਲੋ ਹੈ: ਜੋ ਤੁਸੀਂ ਭੇਜਦੇ ਹੋ ਉਸ ਨੂੰ ਸਮੀਖਿਆ ਕਰੋ, ਇਸ ਨੂੰ ਲਗਾਤਾਰ ਸਮੀਖਿਆ ਵਿੱਚ ਰੱਖੋ, ਅਤੇ ਅਸਪਸ਼ਟਤਾ ਨੂੰ ਇੱਕ ਬੱਗ ਮੰਨੋ।\n\n### ਆਡੀਟਿੰਗ ਕੀ ਦਿਖਦੀ ਹੈ (ਸਰਲ ਪੜਹਾਈ ਤੋਂ ਬਾਹਰ)\n\nਸਿਸਟਮੈਟਿਕ ਸਮੀਖਿਆ ਕੇਵਲ ਸਾਫ਼-ਸੁਥਰੇ ਗਲਤੀਆਂ ਲਈ ਸਕੈਨ ਕਰਨ ਵਾਲੀ ਗੱਲ ਨਹੀਂ। ਇਸ ਵਿੱਚ ਆਮ ਤੌਰ 'ਤੇ ਸ਼ਾਮਲ ਹੁੰਦਾ ਹੈ:\n\n- ਸਪੱਸ਼ਟ ਸ਼ਬਦਾਂ ਵਿੱਚ ਥ੍ਰੇਟ ਮਾਡਲਿੰਗ: ਹਮਲਾਵਰ ਕਿਹੜੇ ਇਨਪੁੱਟ ਨੂੰ ਨਿਯੰਤਰਿਤ ਕਰ ਸਕਦਾ ਹੈ? ਜੇ ਉਹ ਸਭ ਤੋਂ ਬੁਰਾ ਡੇਟਾ ਸਭ ਤੋਂ ਬੁਰੇ ਸਮੇਂ ਭੇਜੇ ਤਾਂ ਕੀ ਹੁੰਦਾ?\n- API ਅਤੇ ਇੰਟਰਫੇਸ ਸਮੀਖਿਆ: ਕੀ ਫੰਕਸ਼ਨ ਆਸਾਨੀ ਨਾਲ ਗਲਤ ਵਰਤੇ ਜਾ ਸਕਦੇ ਹਨ? ਕੀ ਉਹ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਫੇਲ ਹੁੰਦੇ ਹਨ? ਕੀ ਡਿਫੌਲਟ ਸੰਭਾਲੇ ਹੋਏ ਹਨ?\n- ਸਾਫ਼-ਸਫਾਈ ਅਤੇ ਸਰਲਤਾ: ਮਰੇ ਹੋਏ ਕੋਡ ਹਟਾਉਣਾ, ਬਾਊਂਡ ਤੰਗ ਕਰਨਾ, ਅਸਪਸ਼ਟ ਵਿਹਾਰ ਘਟਾਉਣਾ, ਅਤੇ ਕੰਟਰੋਲ ਫਲੋ ਨੂੰ ਆਸਾਨੀ ਨਾਲ ਸਮਝਣਾ।\n\nਇੱਕ ਮੁੱਖ ਵਿਚਾਰ ਇਹ ਹੈ ਕਿ ਆਡਿਟਸ ਅਕਸਰ ਪੂਰੀਆਂ ਬੱਗ-ਕਲਾਸਾਂ ਨੂੰ ਰੋਕਣ ਦਾ ਟੀਚਾ ਰੱਖਦੀਆਂ ਹਨ, ਨਾ ਕਿ ਸਿਰਫ਼ ਇਕ ਰਿਪੋਰਟ ਕੀਤੀ ਸਮੱਸਿਆ ਨੂੰ ਠੀਕ ਕਰਨ।\n\n### ਉੱਚ-ਮੁੱਲ ਵਾਲੇ ਲਕਸ਼: ਜਿੱਥੇ ਬੱਗ ਛੁਪਦੇ ਹਨ\n\nਆਡੀਟਸ ਉਨ੍ਹਾਂ ਹਿੱਸਿਆਂ 'ਤੇ ਧਿਆਨ ਕੇਂਦ੍ਰਿਤ ਕਰਦੀਆਂ ਹਨ ਜੋ ਅਣ-ਅਧਿਕਾਰਸ਼ੀਲ ਇਨਪੁੱਟ ਪਾਰਸ ਕਰਦੇ ਹਨ ਜਾਂ ਉੱਚ-ਖਤਰੇ ਵਾਲੇ ਓਪਰੇਸ਼ਨਾਂ ਨੂੰ ਸੰਭਾਲਦੇ ਹਨ। ਆਮ ਲਕਸ਼ ਸ਼ਾਮਲ ਹਨ:\n\n- ਪਾਰਸਰ ਅਤੇ ਫਾਇਲ ਫਾਰਮੈਟ (ਕੋਈ ਵੀ ਚੀਜ਼ ਜੋ ਜਟਿਲ, ਹਮਲਾਵਰ-ਨਿਯੰਤਰਿਤ ਡੇਟਾ ਪੜ੍ਹਦੀ ਹੈ)\n- ਕ੍ਰਿਪਟੋਗ੍ਰਾਫੀ ਅਤੇ ਕੀ ਸੰਭਾਲ (ਖਾਸ ਕਰਕੇ ਐਰਰ ਪਾਥ ਅਤੇ ਐਡਜ ਕੇਸ)\n- ਨੈੱਟਵਰਕ-ਮੁਖੀ ਡੇਮਨਸ (ਪ੍ਰਮਾਣੀਕਰਨ, ਸੈਸ਼ਨ ਪ੍ਰਬੰਧਨ, ਅਤੇ ਪ੍ਰੋਟੋਕਾਲ ਸਟੇਟ ਮਸ਼ੀਨ)\n\nਇਹ ਖੇਤਰ ਅਕਸਰ ਜਟਿਲਤਾ ਅਤੇ ਪਹੁੰਚ ਨੂੰ ਮਿਲਾਂਦੇ ਹਨ—ਬਿਲਕੁਲ ਉਹ ਥਾਂ ਜਿੱਥੇ ਨਾਜ਼ੁਕ ਖਾਮੀਆਂ ਫਲਦੀਆਂ ਹਨ।\n\n### ਵਪਾਰ-ਅਧਿਕਾਰ ਅਤੇ ਸੀਮਾਵਾਂ\n\nਲਗਾਤਾਰ ਕੋਡ ਸਮੀਖਿਆ ਸਮਾਂ ਅਤੇ ਕੇਂਦ੍ਰਿਤ ਅਭਿ਼ਯੋਗਤਾ ਲੈਂਦੀ ਹੈ। ਇਹ ਫੀਚਰ ਕੰਮ ਨੂੰ ਧੀਮਾ ਕਰ ਸਕਦਾ ਹੈ, ਅਤੇ ਇਹ ਗਾਰੰਟੀ ਨਹੀਂ: ਸਮੀਖਿਆਕਾਰ ਚੀਜ਼ਾਂ ਮਿਸ ਕਰਦੇ ਹਨ, ਅਤੇ ਨਵਾਂ ਕੋਡ ਪੁਰਾਣੀਆਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਦੁਬਾਰਾ ਲਿਆ ਸਕਦਾ ਹੈ।\n\nOpenBSD ਦਾ ਪਾਠ ਜਾਦੂਈ ਨਹੀਂ, ਬਲਕਿ ਦੀਪਕ ਹੈ: ਅਨੁਸ਼ਾਸ਼ਿਤ ਆਡੀਟਿੰਗ ਜਦੋਂ ਲਗਾਤਾਰ ਇੰਜੀਨੀਅਰਿੰਗ ਕੰਮ ਵਜੋਂ ਮੰਨੀ ਜਾਂਦੀ ਹੈ ਤਾਂ ਜੋ ਜੋਖ਼ਮ ਮਹੱਤਵਪੂਰਨ ਤੌਰ 'ਤੇ ਘਟਦਾ ਹੈ।\n\n## ਡਿਜ਼ਾਈਨ ਡਿਫੌਲਟ ਵਜੋਂ ਲੀਸਟ ਪ੍ਰਿਵਿਲੇਜ ਅਤੇ ਪ੍ਰਿਵਿਲੇਜ ਵੰਡ\n\nਸੁਰੱਖਿਆ ਕੇਵਲ ਕੁਝ ਗੜਬੜ ਹੋਣ 'ਤੇ ਰੱਖਿਆ ਜੋੜਨ ਬਾਰੇ ਨਹੀਂ ਹੈ। OpenBSD ਨੇ ਇੱਕ ਵੱਖਰੀ ਸੁਝਾਅ ਧਕਾ ਦਿੱਤਾ: ਪਹਿਲਾਂ ਮੰਨੋ ਕਿ ਸਾਫਟਵేర్ ਵਿੱਚ ਬੱਗ ਹੋ ਸਕਦੇ ਹਨ, ਫਿਰ ਸਿਸਟਮ ਨੂੰ ਅਜਿਹਾ ਡਿਜ਼ਾਈਨ ਕਰੋ ਕਿ ਬੱਗਾਂ ਦੀ ਸ਼ਕਤੀ ਸੀਮਤ ਰਹੇ।\n\n### ਸਧਾਰਨ-ਭਾਸ਼ਾ ਵਿੱਚ ਲੀਸਟ ਪ੍ਰਿਵਿਲੇਜ\n\n"ਲੀਸਟ ਪ੍ਰਿਵਿਲੇਜ" ਦਾ ਅਰਥ ਹੈ ਕਿ ਇਕ ਪ੍ਰੋਗਰਾਮ ਜਾਂ ਯੂਜ਼ਰ ਸਿਰਫ਼ ਉਹ ਅਧਿਕਾਰ ਰੱਖੇ ਜੋ ਇਸਦੇ ਕੰਮ ਲਈ ਲੋੜੀਂਦੇ ਹਨ—ਅਤੇ ਹੋਰ ਕੁਝ ਨਹੀਂ। ਜੇ ਇੱਕ ਵੈੱਬ ਸਰਵਰ ਸਿਰਫ਼ ਆਪਣੀ ਕੰਫਿਗ ਪੜ੍ਹਨ ਅਤੇ ਇੱਕ ਡਾਇਰੈਕਟਰੀ ਤੋਂ ਫਾਇਲ ਸਰਵ ਕਰਨਾ ਚਾਹੁੰਦਾ ਹੈ, ਤਾਂ ਉਸਨੂੰ ਹਰ ਕਿਸੇ ਦੇ ਹੋਮ ਫੋਲਡਰ ਪੜ੍ਹਨ ਜਾਂ ਸਿਸਟਮ ਸੈਟਿੰਗ ਬਦਲਣ ਜਾਂ ਰਾ ਡਿਵਾਈਸ ਤੱਕ ਪਹੁੰਚ ਨਹੀਂ ਹੋਣੀ ਚਾਹੀਦੀ।\n\nਇਹ ਲੋੜੀਂਦੀ ਹੈ ਕਿਉਂਕਿ ਜਦ ਕੁਝ ਟੁੱਟਦਾ ਹੈ (ਜਾਂ ਐਕਸਪਲੋਇਟ ਹੁੰਦਾ ਹੈ), ਨੁਕਸਾਨ ਉਸ ਅਘੇ ਵੇ ਪੀ ਸੀਮਿਤ ਹੁੰਦਾ ਹੈ ਜੋ ਇਸ ਕੰਪੋਨੈਂਟ ਨੂੰ ਮਿਲੇ ਹਨ।\n\n### ਪ੍ਰਿਵਿਲੇਜ ਵੰਡ: ਅੱਗੇ ਵਾਲੇ ਦਰਵਾਜ਼ੇ ਦੀਆਂ ਚਾਬੀਆਂ ਨਾ ਦੇਵੋ\n\nਨੈੱਟਵਰਕ-ਮੁਖੀ ਪ੍ਰੋਗਰਾਮ ਹਰ ਰੋਜ ਅਣ-ਭਰੋਸੇਯੋਗ ਇਨਪੁੱਟ ਦੇ ਸਾਹਮਣੇ ਹੁੰਦੇ ਹਨ: ਵੈੱਬ ਰਿਕੁਐਸਟ, SSH ਲੌਗਿਨ ਕੋਸ਼ਿਸ਼ਾਂ, ਮਾਲਫਾਰਮਡ ਪੈਕਟ।\n\nਪ੍ਰਿਵਿਲੇਜ ਵੰਡ ਇੱਕ ਪ੍ਰੋਗਰਾਮ ਨੂੰ ਛੋਟੇ ਹਿੱਸਿਆਂ ਵਿੱਚ ਵੰਡਦੀ ਹੈ:\n\n- ਇੱਕ ਘੱਟ-ਅਧਿਕਾਰਸ਼ੀਲ, ਸੀਮਤ "ਪ੍ਰਿਵਿਲੇਜਡ" ਸਹਾਇਕ ਜੋ সংਵੇਦਨਸ਼ੀਲ ਕਾਰਜ ਕਰ ਸਕਦਾ ਹੈ।\n- ਇੱਕ ਜਾਂ ਕਈ ਅਣ-ਅਧਿਕਾਰਸ਼ੀਲ ਪ੍ਰਕਿਰਿਆਵਾਂ ਜੋ ਜੋਖਿਮ ਭਰਿਆ ਪਾਰਸਿੰਗ ਅਤੇ ਨੈੱਟਵਰਕ ਇੰਟਰਐਕਸ਼ਨ ਸੰਭਾਲਦੀਆਂ ਹਨ।\n\nਇਸ ਤਰ੍ਹਾਂ ਜੇ ਹਮਲਾਵਰ ਇੰਟਰਨੈੱਟ-ਨਜ਼ਦੀਕੀ ਹਿੱਸੇ ਵਿੱਚ ਕਿਸੇ ਬੱਗ ਨੂੰ ਲੱਭ ਲੈਂਦਾ ਹੈ, ਉਹ ਆਪਣੇ ਆਪ ਸਿਸਟਮ 'ਤੇ ਪੂਰੀ ਕੰਟਰੋਲ ਨਹੀਂ ਹਾਸਲ ਕਰ ਲੈਂਦਾ। ਉਹ ਇੱਕ ਥਾਂ ਵਿੱਚ ਪਹੁੰਚਦਾ ਹੈ ਜਿਸਦੇ ਅਧਿਕਾਰ ਘੱਟ ਹਨ ਅਤੇ ਉਸਨੂੰ ਉਦੋਂ ਹੀ ਪਰਵਾਨਗੀ ਵਧਾਉਣ ਦੇ ਘੱਟ ਰਾਹ ਮਿਲਦੇ ਹਨ।\n\n### ਸੈਂਡਬਾਕਸਿੰਗ ਅਤੇ ਪ੍ਰਕਿਰਿਆ ਅਲੱਗ ਕਰਨ ਵਜੋਂ ਸੰਭਾਲ\n\nOpenBSD ਨੇ ਇਸ ਵੰਡ ਨੂੰ ਹੋਰ OS-ਧਰ ਦੇ ਸੀਮਤਾਂ (ਜਿਵੇਂ chroot ਜੇਲਾਂ ਅਤੇ ਹੋਰ ਰੀਸਟਰਿਕਸ਼ਨ) ਨਾਲ ਮਜ਼ਬੂਤ ਕੀਤਾ। ਇਸਨੂੰ ਇੱਕ ਖ਼ਤਰਨਾਕ ਹਿੱਸੇ ਨੂੰ ਲਾਕ ਕੀਤੇ ਕਮਰੇ ਵਿੱਚ ਚਲਾਉਣ ਵਾਂਗ ਸੋਚੋ: ਇਹ ਆਪਣਾ ਸੰਕੁਚਿਤ ਕੰਮ ਕਰ ਸਕਦਾ ਹੈ, ਪਰ ਘਰ ਵਿੱਚ ਘੁੰਮ ਨਹੀਂ ਸਕਦਾ।\n\n### ਪਹਿਲਾਂ/ਬਾਅਦ ਦਾ ਮਾਨਸਿਕ ਮਾਡਲ\n\nਪਹਿਲਾਂ: ਇੱਕ ਵੱਡਾ ਡੇਮਨ ਚੌੜੇ ਅਧਿਕਾਰਾਂ ਨਾਲ ਚੱਲਦਾ → ਇੱਕ ਹਿੱਸੇ ਦਾ ਸੰਕ੍ਰਮਣ ਸਾਰੇ ਸਿਸਟਮ ਦਾ ਸੰਕ੍ਰਮਣ।\n\nਬਾਅਦ: ਛੋਟੇ, ਵੱਖ-ਵੱਖ ਹਿੱਸੇ ਘੱਟ ਅਧਿਕਾਰਾਂ ਨਾਲ → ਇੱਕ ਹਿੱਸੇ ਦਾ ਸੰਕ੍ਰਮਣ, ਸੀਮਤ ਫੁੱਟਹੋਲਡ; ਹਰ ਕਦਮ 'ਤੇ ਰੁਕਾਵਟਾਂ।\n\n## ਐਕਸਪਲੋਇਟ ਮਿਟੀਗੇਸ਼ਨ ਜਿਹਨਾਂ ਨੇ ਉਮੀਦਾਂ ਬਦਲ ਦਿੱਤੀਆਂ\n\nਕਈ ਸਾਲਾਂ ਤੱਕ, ਅਸਲ-ਦੁਨੀਆ ਦੇ ਬਹੁਤ ਸਾਰੇ ਸੰਕ੍ਰਮਣ ਮੈਮੋਰੀ ਸੁਰੱਖਿਆ ਬੱਗਾਂ ਨਾਲ ਸ਼ੁਰੂ ਹੋਏ: ਬਫਰ ਓਵਰਫਲੋਜ਼, ਯੂਜ਼-ਆਫਟਰ-ਫਰੀ, ਆਦਿ। ਇਹ ਗਲਤੀਆਂ ਹਮਲਾਵਰ ਨੂੰ ਕੰਟਰੋਲ ਡੇਟਾ ਓਵਰਰਾਈਟ ਕਰਨ ਅਤੇ ਇਰਬਟਰੀ ਕੋਡ ਚਲਾਉਣ ਦੀ ਆਗਿਆ ਦਿੰਦੀਆਂ ਸਨ।\n\nOpenBSD ਨੇ ਇਸ ਹਕੀਕਤ ਨੂੰ ਇਕ ਪ੍ਰਾਇਗਮੈਟਿਕ ਇੰਜੀਨੀਅਰਿੰਗ ਸਮੱਸਿਆ ਵਜੋਂ ਲਿਆ: ਮੰਨੋ ਕੁਝ ਬੱਗ-slip ਹੋਣਗੇ, ਫਿਰ ਸਿਸਟਮ ਨੂੰ ਐਸਾ ਬਣਾਓ ਕਿ ਉਹਨਾਂ ਦਾ ਐਕਸਪਲੋਇਟ ਕਰਨਾ ਔਖਾ, ਸ਼ੋਰ ਕਰਨ ਵਾਲਾ, ਅਤੇ ਘੱਟ ਭਰੋਸੇਯੋਗ ਹੋਵੇ।\n\n### ਐਕਸਪਲੋਇਟ ਕਰਨ ਦੀ ਕੀਮਤ ਵਧਾਉਣਾ\n\nOpenBSD ਨੇ ਉਹ ਮਿਟੀਗੇਸ਼ਨਾਂ ਨੂੰ ਸਧਾਰਨ ਕੀਤਾ ਜੋ ਅੱਜ ਕਈ ਲੋਕ ਆਮ ਸਮਝਦੇ ਹਨ:\n\n- W^X (Write XOR Execute): ਮੈਮੋਰੀ ਪੇਜਾਂ ਜਾਂ ਤਾਂ ਲਿਖਣਯੋਗ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ ਜਾਂ ਚਲਾਉਣ ਯੋਗ, ਦੋਹਾਂ ਨਹੀਂ। ਇਹ ਕਲਾਸਿਕ "ਸ਼ੈਲਕੋਡ ਇੰਜੈਕਟ ਕਰਕੇ ਕੂਦੋ" ਹਮਲੇ ਨੂੰ ਔਖਾ ਕਰਦਾ ਹੈ।\n- ASLR (Address Space Layout Randomization): ਕੋਡ ਅਤੇ ਡੇਟਾ ਕਿੱਥੇ ਰਹਿੰਦੇ ਹਨ ਨੂੰ ਰੈਂਡਮ ਬਣਾਉਣਾ ਰਿਟਰਨ-ਓਰਿєнਟਿਡ ਪ੍ਰੋਗਰਾਮਿੰਗ ਵਰਗੀਆਂ ਤਕਨੀਕਾਂ ਲਈ ਪਤੇ ਭਵਿੱਖਬਾਣੀ ਔਖੀ ਕਰਦਾ ਹੈ।\n- ਸਟੈਕ ਪ੍ਰੋਟੈਕਸ਼ਨ: ਕੰਪਾਇਲਰ ਅਤੇ ਰਨਟਾਈਮ ਰੱਖਿਆ (ਜਿਵੇਂ ਸਟੈਕ ਕੇਨਰੀਜ਼) ਸਟੈਕ-ਸਮੇਸ਼ਿੰਗ ਨੂੰ ਰੋਕਣ ਜਾਂ ਪਤਾ ਲਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਨ।\n\nਇਹ ਯੰਤਰ "ਜਾਦੂਈ ਢਾਲ" ਨਹੀਂ ਹਨ। ਉਹ ਹੁੰਦੇ ਹਨ ਸਪੇਡ-ਬੰਧ: ਅਕਸਰ ਬਹੁਤ ਪ੍ਰਭਾਵਸ਼ਾਲੀ, ਜੋ ਹਮਲਾਵਰਾਂ ਨੂੰ ਹੋਰ ਕਦਮ ਜੋੜਨ 'ਤੇ ਮਜ਼ਬੂਰ ਕਰਦੇ ਹਨ, ਵਧੇਰੇ ਇਨਫੋ-ਲੀਕਾਂ ਦੀ ਲੋੜ ਪੈਂਦੀ ਹੈ, ਜਾਂ ਭਰੋਸੇਯੋਗਤਾ ਘੱਟ ਹੋ ਜਾਂਦੀ ਹੈ।\n\n### ਡਿਫ਼ੈਂਸ-ਇਨ-ਡੈਪਥ, ਬਿਨਾਂ ਮੁਫ਼ਤ ਪਾਸ ਦੇ\n\nਗਹਿਰੀ ਸਿੱਖਿਆ ਇਹ ਹੈ ਕਿ ਮਿਟੀਗੇਸ਼ਨਾਂ ਇੱਕ ਮੁਫ਼ਤ ਛੂਟ ਨਹੀਂ ਹਨ: ਉਹ ਸਮਾਂ ਖਰੀਦਦੇ ਹਨ, ਬਲਾਸਟ ਰੇਡੀਅਸ ਘਟਾਉਂਦੇ ਹਨ, ਅਤੇ ਕੁਝ ਖਾਮੀਆਂ ਨੂੰ ਕਰੈਸ਼ ਵਿੱਚ ਬਦਲ ਦਿੰਦੇ ਹਨ ਨਾ ਕਿ ਪੂਰੇ ਸਿਸਟਮ ਦੇ ਹੱਥ ਖੋਹ। ਇਹ ਓਪਰੇਸ਼ਨਲੀ ਤੌਰ 'ਤੇ ਅਹੰਕਾਰਪੂਰਣ ਹੈ ਕਿਉਂਕਿ ਇਹ ਲੱਭਣ ਅਤੇ ਪੈਚ ਕਰਨ ਦੇ ਦਰਮਿਆਨ ਵੱਕੜ ਨੂੰ ਘਟਾ ਸਕਦਾ ਹੈ।\n\nਪਰ ਮਿਟੀਗੇਸ਼ਨਜ਼ ਮੂਲ ਬੱਗਾਂ ਨੂੰ ਠੀਕ ਕਰਨ ਦੀ ਥਾਂ ਨਹੀਂ ਲੈਂਦੀਆਂ। OpenBSD ਦੀ ਫਿਲਾਸਫੀ ਨੇ ਐਕਸਪਲੋਇਟ ਰੋਹਬਧਤਾ ਨੂੰ ਬ不停 ਬੱਗ ਫਿਕਸਿੰਗ ਅਤੇ ਸਮੀਖਿਆ ਨਾਲ ਜੋੜਿਆ: ਅੱਜ ਐਕਸਪਲੋਇਟ ਕਰਨਾ ਔਖਾ ਬਣਾਉ, ਅਤੇ ਕੱਲ੍ਹ ਮੂਲ ਬੱਗਾਂ ਨੂੰ ਹਟਾਉਣ ਜਾਰੀ ਰੱਖੋ।\n\n## ਕ੍ਰਿਪਟੋਗ੍ਰਾਫੀ, ਰੈਂਡਮਨੈੱਸ ਅਤੇ ਸੁਰੱਖਿਅਤ ਇੰਟਰਫੇਸ\n\nOpenBSD ਦੀ ਸੁਰੱਖਿਆ ਖ੍ਯਾਤੀ "ਹਰ ਥਾਂ ਹੋਰ ਜ਼ਿਆਦਾ ਕ੍ਰਿਪਟੋ" ਉੱਤੇ ਨਹੀਂ ਬਣੀ। ਇਹ ਸਹੀਪਨ ਉੱਤੇ ਬਣੀ ਹੈ: ਘੱਟ ਹੈਰਾਨੀ, ਸਾਫ਼ ਏਪੀਆਈ, ਅਤੇ ਉਹ ਵਿਹਾਰ ਜਿਸ ਨੂੰ ਤੁਹਾਨੂੰ ਦਬਾਅ ਹੇਠ ਵੀ ਸੋਚ ਸਕਣਾ ਚਾਹੀਦਾ ਹੈ।\n\nਇਹ ਮਨੋਵਿਗਿਆਨ ਕਿਵੇਂ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫੀ ਏਡੀਸ਼ਨ, ਰੈਂਡਮਨੈੱਸ ਪੈਦਾ ਕਰਨ ਅਤੇ ਇੰਟਰਫੇਸ ਡਿਜ਼ਾਈਨ ਵਿੱਚ ਪਰਛਾਵਾਂ ਦਿਖਾਉਂਦਾ ਹੈ, ਤਾਂ ਜੋ ਗਲਤ ਚੋਣਾਂ ਗਲਤੀ ਨਾਲ ਕਰਨਾ ਔਖਾ ਹੋ ਜਾਵੇ।\n\n### ਸਹੀਪਨ ਅਤੇ ਸਪਸ਼ਟ ਏਪੀਆਈ ਚੁਣਾਵਾਂ ਚਤੁਰਾਈ ਤੋਂ ਵਧ ਕੇ ਹਨ\n\nOpenBSD ਦੀ ਬਾਰ-ਬਾਰ ਲੈਖਸ਼ ਹੈ ਕਿ ਸੁਰੱਖਿਆ ਨਾਕਾਮੀਆਂ ਅਕਸਰ ਆਮ ਬੱਗਾਂ ਵਜੋਂ ਸ਼ੁਰੂ ਹੁੰਦੀਆਂ ਹਨ: ਪਾਰਸਿੰਗ ਐਡਜ ਕੇਸ, ਅਸਪਸ਼ਟ ਫ਼ਲੈਗ, ਸ਼ਾਂਤ ਟ੍ਰੰਕੇਸ਼ਨ, ਜਾਂ "ਮਦਦਗਾਰ" ਡਿਫੌਲਟ ਜੋ ਤਰੁਟੀਆਂ ਨੂੰ ਛੁਪਚਾਪ ਰੱਖਦੇ ਹਨ।\n\nਪਰੋਜੈਕਟ ਛੋਟੇ, ਆਡੀਟ ਕਰਨ ਯੋਗ ਇੰਟਰਫੇਸ ਨੂੰ ਤਰਜੀਹ ਦਿੰਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਦੇ ਵਿਫਲ ਹੋਣ ਦੇ ਢੰਗ ਸਪਸ਼ਟ ਹਨ, ਭਾਵੇਂ ਇਸ ਦਾ ਮਤਲਬ ਹੋ ਕਿ ਕੁਝ ਪ੍ਰਚਲਿਤ ਵਿਵਹਾਰ ਨੂੰ ਹਟਾਇਆ ਜਾਂ ਦੁਬਾਰਾ ਡਿਜ਼ਾਇਨ ਕੀਤਾ ਜਾਵੇ।\n\nਸਪਸ਼ਟ ਏਪੀਆਈਆਂ "ਕਨਫਿਗਰੇਸ਼ਨ ਫੁੱਟ-ਗਨਜ਼" ਘਟਾਉਂਦੀਆਂ ਹਨ। ਜੇ ਇੱਕ ਸੁਰੱਖਿਅਤ ਵਿਕਲਪ ਲਭਣ ਲਈ ਬਹੁਤ ਸਾਰੇ ਟੌਗਲਾਂ ਦੀ ਲੜੀ ਦੀ ਲੋੜ ਪਵੇ, ਤਾਂ ਬਹੁਤ ਸਾਰੀਆਂ ਡਿਪਲੋਇਮੈਂਟ ਜ਼ਰੂਰਤ ਨਾਲ ਅਣਸੁਰੱਖਿਅਤ ਰਹਿ ਜਾਂਦੀਆਂ ਹਨ।\n\n### ਰਖ-ਰਖਾਅ ਵਾਲੇ ਕ੍ਰਿਪਟੋ ਚੋਣਾਂ\n\nOpenBSD ਦੀ ਕੌਂਸਲਟੇਟਿਵ ਨਜ਼ਰੀਆ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫੀ ਨੂੰ ਚੁਣਦਿਆਂ ਇਹ ਹੈ: ਚੰਗੇ ਤੌਰ 'ਤੇ ਸਮਝਿਆ ਹੋਇਆ ਪ੍ਰਿਂਮਿਵਟਿਵ ਵਰਤੋ, ਸਾਵਧਾਨੀ ਨਾਲ ਇੰਟੇਗ੍ਰੇਟ ਕਰੋ, ਅਤੇ ਸਿਰਫ਼ ਪਿੱਛੇ-ਰਹਿਣ ਲਈ ਮੌਜੂਦ ਪੁਰਾਣੀਆਂ ਵਿਵਹਾਰਾਂ ਨੂੰ ਯੂਜ਼ ਨਾ ਕਰੋ।\n\nਇਹ ਡਿਫੌਲਟਾਂ ਵਿੱਚ ਦਿੱਖਦਾ ਹੈ ਜੋ ਮਜ਼ਬੂਤ ਐਲਗੋਰਿਥਮਾਂ ਨੂੰ ਤਰਜੀਹ ਦਿੰਦੇ ਹਨ ਅਤੇ ਬੁਰੇ, ਪੁਰਾਣੇ ਵਿਕਲਪਾਂ ਨੂੰ ਡੀਪ੍ਰਿਕੇਟ ਕਰਨ ਲਈ ਤਿਆਰ ਰਹਿੰਦੇ ਹਨ। ਮਕਸਦ ਹਰ ਸੰਭਵ ਸਾਇਫਰ ਸੁੱਟ ਦੀ ਪੇਸ਼ਕਸ਼ ਨਹੀਂ, ਬਲਕਿ ਸੁਰੱਖਿਅਤ ਰਾਹ ਨੂੰ ਆਮ ਰਾਹ ਬਣਾਉਣਾ ਹੈ।\n\n### ਰੈਂਡਮਨੈੱਸ, ਪਾਰਸਿੰਗ ਅਤੇ ਲੁਕਿਆ ਹੋਇਆ ਜਟਿਲਤਾ\n\nਕਈ ਅਸਲ-ਦੁਨੀਆ ਦੀਆਂ ਨੁਕਸਾਨੀਆਂ ਕਮਜ਼ੋਰ ਰੈਂਡਮਨੈੱਸ, ਅਸੁਰੱਖਿਅਤ ਪਾਰਸਿੰਗ, ਜਾਂ ਕੰਫਿਗ ਪਰਤਾਂ ਵਿੱਚ ਲੁਕਿਆ ਹੋਇਆ ਜਟਿਲਤਾ ਕਾਰਨ ਹੁੰਦੀਆਂ ਹਨ।\n\nਕਮਜ਼ੋਰ ਰੈਂਡਮਨੈੱਸ ਮਜ਼ਬੂਤ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫੀ ਨੂੰ ਵੀ ਘਟਾ ਸਕਦੀ ਹੈ, ਇਸ ਲਈ ਡਿਫੌਲਟ-ਤੌਰ ਤੇ ਸੁਰੱਖਿਅਤ ਸਿਸਟਮ ਐਨਟ੍ਰੋਪੀ ਅਤੇ ਰੈਂਡਮ APIs ਨੂੰ ਮਹੱਤਵਪੂਰਨ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਵਜੋਂ ਲੈਂਦੇ ਹਨ, ਨਾ ਕਿ ਬਾਅਦ ਵਿੱਚ ਸੋਚਣ ਯੋਗ ਚੀਜ਼।\n\nਅਸੁਰੱਖਿਅਤ ਪਾਰਸਿੰਗ (ਕੀਜ਼, ਸਰਟੀਫਿਕੇਟ, ਕੰਫਿਗ ਫਾਇਲਾਂ, ਜਾਂ ਨੈੱਟਵਰਕ ਇਨਪੁੱਟ) ਇੱਕ ਹੋਰ ਮੁੜ-ਆਉਣ ਵਾਲੀ ਸਮੱਸਿਆ ਹੈ; ਪੇਸ਼ਗੀ ਫਾਰਮੈਟ, ਸਖਤ ਵੈਰੀਫਿਕੇਸ਼ਨ, ਅਤੇ ਸੁਰੱਖਿਅਤ ਸਟਰਿੰਗ ਹੈਂਡਲਿੰਗ ਹਮਲਾ ਸਤਹ ਘਟਾਉਂਦੇ ਹਨ।\n\nਅਖੀਰਕਾਰ, "ਲੁਕਿਆ" ਕੰਫਿਗਰੇਸ਼ਨ ਜਟਿਲਤਾ ਹੀ ਖ਼ਤਰਾ ਹੈ: ਜਦੋਂ ਸੁਰੱਖਿਆ ਨਾਜ਼ੁਕ ਆਰਡਰਿੰਗ ਨਿਯਮਾਂ ਜਾਂ ਅਣਦਸਤਾਵੇਜ਼ ਇੰਟਰਐਕਸ਼ਨਾਂ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ, ਤਾਂ ਗਲਤੀਆਂ ਅਟੱਲ ਹੋ ਜਾਂਦੀਆਂ ਹਨ।\n\nOpenBSD ਦੀ ਪਸੰਦ ਇਹ ਹੈ ਕਿ ਇੰਟਰਫੇਸ ਸਧਾਰਨ ਰਹੇ ਅਤੇ ਡਿਫੌਲਟ ਉਹ ਚੁਣੇ ਜਾਣ ਜੋ ਚੁਪਚਾਪ ਅਣਸੁਰੱਖਿਅਤ ਲੈਗਸੀ ਵਿਵਹਾਰ ਨੂੰ ਵਿਰਾਸਤ ਨਾ ਕਰੇ।\n\n## OpenSSH ਅਤੇ OpenBSD ਸੁਰੱਖਿਆ ਸੋਚ ਦਾ ਫੈਲਾਅ\n\nOpenSSH ਇੱਕ ਸਭ ਤੋਂ ਸਪਸ਼ਟ ਉਦਾਹਰਣ ਹੈ ਕਿ ਕਿਵੇਂ OpenBSD ਦੀ ਸੁਰੱਖਿਆ ਫਲਸਫ਼ਾ ਪ੍ਰੋਜੈਕਟ ਤੋਂ ਬਾਹਰ ਨਿਕਲ ਕੇ ਹੋਰ ਥਾਂਆਂ 'ਤੇ ਡਿਫੌਲਟ ਉਮੀਦ ਬਣ ਗਈ।\n\nਜਦੋਂ SSH ਯੂਨੀਕਸ ਅਤੇ ਲਿਨਕਸ ਪ੍ਰਣਾਲੀਆਂ ਨੂੰ ਦੂਰ-ਦਰਾਜ਼ ਪ੍ਰਬੰਧਨ ਲਈ ਮਿਆਰੀ ਰਾਹ ਬਣ ਗਿਆ, ਤਾਂ ਸਵਾਲ ਇਹ ਨਹੀਂ ਸੀ "ਕੀ ਅਸੀਂ ਦੂਰਲੇ ਲੌਗਇਨ ਨੂੰ ਇਨਕ੍ਰਿਪਟ ਕਰੀਏ?"—ਸਵਾਲ ਸੀ "ਕਿਹੜਾ ਇੰਪਲੀਮੇਂਟੇਸ਼ਨ ਇਸਨੂੰ ਹਮੇਸ਼ਾ, ਹਰ ਥਾਂ ਭਰੋਸੇਯੋਗ ਤਰੀਕੇ ਨਾਲ ਚਲਾਏਗਾ?"\n\n### ਇੱਕ SSH ਫੋਰਕ ਤੋਂ ਸੁਰੱਖਿਆ ਮਿਆਰ ਤੱਕ\n\nOpenSSH ਉਸ ਵੇਲੇ ਉਭਰਿਆ ਜਦੋਂ ਅਸਲੀ ਮੁਫ਼ਤ SSH ਇੰਪਲੀਮੈਂਟੇਸ਼ਨ (SSH 1.x) ਦੇ ਲਾਇਸੈਂਸ ਬਦਲ ਰਹੇ ਸਨ ਅਤੇ ਈਕੋਸਿਸਟਮ ਨੂੰ ਇੱਕ ਆਜ਼ਾਦ, ਸਰਗਰਮ ਤੌਰ 'ਤੇ ਰੱਖਿਆ ਹੋਇਆ ਵਿਕਲਪ ਚਾਹੀਦਾ ਸੀ।\n\nOpenBSD ਨੇ ਸਿਰਫ਼ ਇੱਕ ਬਦਲ ਨਹੀਂ ਦਿੱਤਾ; ਇਸਨੇ ਇਕ ਐਸੀ ਵਰਜ਼ਨ ਦਿੱਤੀ ਜੋ ਇਸ ਦੀ ਸੰਸਕ੍ਰਿਤੀ ਨਾਲ ਬਣੀ ਸੀ: ਸੰਰੱਖਿਤ ਬਦਲਾਵ, ਕੋਡ ਸਪੱਫ਼ਤਾ, ਅਤੇ ਐਸਾ ਰੁਝਾਨ ਜੋ ਹਰ ਐਡਮਿਨ ਨੂੰ ਵਿਸ਼ੇਸ਼ ਗਿਆਨ ਦੀ ਲੋੜ ਛੱਡ ਕੇ ਸੁਰੱਖਿਅਤ ਵਿਹਾਰ ਵੱਲ ਧੱਕੇ।\n\nਇਹ ਵਿਆਪਕ ਤੌਰ 'ਤੇ ਅਹਮ ਸੀ ਕਿਉਂਕਿ SSH ਬਹੁਤ ਸਾਰੀਆਂ ਸਥਿਤੀਆਂ ਵਿੱਚ ਸਭ ਤੋਂ ਸੰਵੇਦਨਸ਼ੀਲ ਰਾਹ 'ਤੇ ਬੈਠਦਾ ਹੈ: ਪ੍ਰਿਵਿਲੇਜ ਐਕਸੈਸ, ਛੇਤਰੀ ਆਟੋਮੇਸ਼ਨ, ਅਤੇ ਐਮਰਜੈਂਸੀ ਰਿਕਵਰੀ। SSH ਵਿੱਚ ਇੱਕ ਕਮਜ਼ੋਰੀ "ਇੱਕ ਹੋਰ ਬੱਗ" ਨਹੀਂ—ਇਹ ਇਕ ਯੂਨੀਵਰਸਲ ਕੁੰਜੀ ਬਣ ਸਕਦੀ ਹੈ।\n\n### ਸੁਰੱਖਿਅਤ ਡਿਫੌਲਟ ਦੂਰਲੇ ਪ੍ਰਬੰਧਨ ਲਈ ਯੋਗਦਾਨ ਦਿੰਦੇ ਹਨ\n\nOpenBSD ਨੇ ਦੂਰਲੇ ਪ੍ਰਬੰਧਨ ਨੂੰ ਇੱਕ ਉੱਚ-ਪੱਧਰ ਦੇ ਵਰਕਫਲੋ ਵਜੋਂ ਦੇਖਿਆ।\n\nOpenSSH ਦੀ ਸੰਰਚਨਾ ਅਤੇ ਸਮਰਥਿਤ ਫੀਚਰ ਐਡਮਿਨਾਂ ਨੂੰ ਬਿਹਤਰ ਪ੍ਰਿਆਨ ਪਾਸੇ ਨੁਹਾਉਂਦੇ ਹਨ: ਮਜ਼ਬੂਤ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫੀ, ਸਹੀ ਪ੍ਰਮਾਣੀਕਰਨ ਵਿਕਲਪ, ਅਤੇ ਗਾਰਡਰੇਲ ਜੋ ਅਣਜਾਣੇ ਐਕਸਪੋਜ਼ਰ ਨੂੰ ਘਟਾਉਂਦੇ ਹਨ।\n\nਇਹੀ ਹੈ "ਡਿਫੌਲਟ-ਤੌਰ ਤੇ ਸੁਰੱਖਿਅਤ" ਕਿ ਅਮਲ ਵਿੱਚ ਦਿਖਾਈ ਦਿੰਦੀ ਹੈ: ਓਪਰੇਟਰ ਦੇ ਮਨ-ਦਬਾਉਂ ਹੇਠ ਮਿਲਣ ਵਾਲੇ ਫੁੱਟਗਨਜ਼ ਦੀ ਗਿਣਤੀ ਘੱਟ ਕਰੋ। ਜਦੋਂ ਤੁਸੀਂ ਰਾਤ 2 ਵਜੇ ਪ੍ਰੋਡਕਸ਼ਨ ਬਾਕਸ ਵਿੱਚ SSH ਕਰ ਰਹੇ ਹੋ, ਡਿਫੌਲਟਸ ਨीतੀਆਂ ਤੋਂ ਵੱਧ ਮੈਕਨੀਕਲ ਮਹੱਤਵ ਰੱਖਦੀਆਂ ਹਨ।\n\n### ਪੋਰਟਬਿਲਿਟੀ—ਸੁਰੱਖਿਆ ਵਿਚਾਰਾਂ ਦਾ ਫੈਲਾਅ\n\nOpenSSH ਨੂੰ ਤਰਫ ਯਾਤਰਾ ਲਈ ਡਿਜ਼ਾਈਨ ਕੀਤਾ ਗਿਆ ਸੀ। Linux, *BSDs, macOS ਅਤੇ ਵਪਾਰਕ Unix 'ਤੇ ਪੋਰਟ ਕਰਨ ਨਾਲ OpenBSD ਦੇ ਸੁਰੱਖਿਆ ਫੈਸਲੇ—API, ਸੰਰਚਨਾ ਰਿਵਾਜ, ਅਤੇ ਹਾਰਡਨਿੰਗ ਰਵੱਈਏ—ਕੋਡ ਦੇ ਨਾਲ-ਨਾਲ ਚਲ ਕੇ ਫੈਲ ਗਏ।\n\nਜੋ ਸੰਸਥਾਵਾਂ ਕਿਸੇ ਸਮੇਂ OpenBSD ਨਹੀਂ ਚਲਾਉਂਦੀਆਂ ਸੀ, ਉਹ ਵੀ OpenSSH ਦੀਆਂ ਰਿਮੋਟ-ਐਕਸੈਸ ਧਾਰਣਾਵਾਂ ਅਪਣਾ ਲੀਆਂ ਕਿਉਂਕਿ OpenSSH ਆਮ ਗੁਣਾ ਬਣ ਗਿਆ।\n\n### ਅਮਲੀ ਨਤੀਜੇ ਜੋ ਮਹਿਸੂਸ ਕੀਤੇ ਜਾ ਸਕਦੇ ਹਨ\n\nਸਭ ਤੋਂ ਵੱਡਾ ਪ੍ਰਭਾਵ ਨਾਜ਼ਰੀ ਨਹੀਂ ਸੀ: ਇਹ ਰੋਜ਼ਾਨਾ ਐਡਮਿਨ ਪੈਟਰਨ ਵਿੱਚ ਦਿਖਿਆ। ਟੀਮਾਂ ਨੇ ਇਨਕ੍ਰਿਪਟਡ ਰਿਮੋਟ ਮੈਨੇਜਮੈਂਟ 'ਤੇ ਸਥਿਰਤਾ ਪਾਈ, ਕੀ-ਆਧਾਰਤ ਫਲੋਅਜ਼ ਨੂੰ ਸੁਧਾਰਿਆ, ਅਤੇ ਇੱਕ ਵਧੀਆਂ ਆਡੀਟ ਕੀਤੇ ਹੁੰਦੇ ਟੂਲ ਨੂੰ ਦੁਨੀਆਂ 'ਤੇ ਤैनਾਤ ਕੀਤਾ।\n\nਸਮੇਂ ਦੇ ਨਾਲ, ਇਸਨੇ "ਨਾਰਮਲ" ਸੁਰੱਖਿਅਤ ਪ੍ਰਬੰਧਨ ਲਈ ਬੇਸਲਾਈਨ ਨੂੰ ਉੱਚਾ ਕੀਤਾ—ਅਤੇ ਅਣਸੁਰੱਖਿਅਤ ਦੂਰਲੇ ਐਕਸੈਸ ਨੂੰ ਬਰਕਰਾਰ ਰੱਖਣਾ ਮੁਸ਼ਕਲ ਬਣਾਇਆ।\n\n## ਰਿਲੀਜ਼ ਇੰਜੀਨੀਅਰਿੰਗ, ਪੈਚਿੰਗ ਅਤੇ ਭਰੋਸਾ\n\n"ਡਿਫੌਲਟ-ਤੌਰ ਤੇ ਸੁਰੱਖਿਅਤ" ਕੇਵਲ ਡਿਜ਼ਾਈਨ ਲਕਸ਼ ਨਹੀਂ—ਇਹ ਇੱਕ ਵਾਅਦਾ ਹੈ ਜੋ ਤੁਸੀਂ ਹਰ ਵਾਰੀ ਭੇਜਦੇ ਹੋ।\n\nOpenBSD ਦੀ ਖ੍ਯਾਤੀ ਬਹੁਤ ਹੱਦ ਤੱਕ ਨਿਯਮਤ ਰਿਲੀਜ਼ ਇੰਜੀਨੀਅਰਿੰਗ 'ਤੇ ਟਿਕੀ ਹੈ: ਪੇਸ਼ਗੋਇਯੋਗ ਰਿਲੀਜ਼, ਧਿਆਨ ਨਾਲ ਕੀਤੇ ਬਦਲਾਵ, ਅਤੇ ਚਤੁਰਾਈ ਉੱਤੇ ਬਿਆਨਾਤ।\n\nਡਿਫੌਲਟਸ ਦਿਨ ਇੱਕ ਤੇ ਸੁਰੱਖਿਅਤ ਹੋ ਸਕਦੇ ਹਨ, ਪਰ ਯੂਜ਼ਰ ਸੁਰੱਖਿਆ ਮਹੀਨਿਆਂ ਅਤੇ ਸਾਲਾਂ ਵਿੱਚ ਅਪਡੇਟਾਂ, ਸਲਾਹ-ਸੂਚਨਾਵਾਂ, ਅਤੇ ਕਿਵੇਂ ਨਿਰਭਰਤਾ ਨਾਲ ਫਿਕਸ ਲਗਾਉਂਦੇ ਹਨ ਉਸ ਰਾਹੀਂ ਮਹਿਸੂਸ ਕਰਦੇ ਹਨ।\n\n### ਪੈਚ ਕੈਡੈਂਸ ਅਤੇ ਸਪਸ਼ਟ ਸਲਾਹ-ਸੂਚਨਾਵਾਂ\n\nਭਰੋਸਾ ਉਸ ਵੇਲੇ ਬਣਦਾ ਹੈ ਜਦ ਅਪਡੇਟ ਨਿਯਮਤ ਹੁੰਦੇ ਹਨ ਅਤੇ ਸੰਚਾਰ ਕਾਰਗਰ ਹੁੰਦਾ ਹੈ। ਇੱਕ ਚੰਗੀ ਸੁਰੱਖਿਆ ਸਲਾਹ-ਸੂਚਨਾ ਚਾਰ ਸਵਾਲਾਂ ਨੂੰ ਬੇ-ਲਾਜ਼ਮੀ ਭਾਸ਼ਾ ਤੋਂ ਬਿਨਾਂ ਉਤਰ ਦੇਣੀ ਚਾਹੀਦੀ ਹੈ: ਕੀ ਪ੍ਰਭਾਵਿਤ ਹੈ? ਪ੍ਰਭਾਵ ਕੀ ਹੈ? ਮੈਂ ਕਿਵੇਂ ਰੀਮੇਡੀਏਟ ਕਰਾਂ? ਮੈਂ ਕਿਵੇਂ ਪੁਸ਼ਟੀ ਕਰਾਂ?\n\nOpenBSD-ਸਟਾਈਲ ਦੇ ਸੰਚਾਰ ਅਕਸਰ ਓੁਲਜਣ-ਭਰੀ ਗੰਭੀਰਤਾ ਦੀ ਭਾਸ਼ਾ ਤੋਂ ਬਚਦੇ ਹਨ ਅਤੇ ਕਾਰਗਰ ਵੇਰਵੇ 'ਤੇ ਧਿਆਨ ਦਿੱਤਾ ਕਰਦੇ ਹਨ—ਵਰਜਨ ਰੇਂਜ, ਪੈਚ ਰੈਫਰੰਸ, ਅਤੇ ਸਬ ਤੋਂ ਘੱਟ ਵਰਕਅਰਰਾਊਂਡ।\n\nਜਿੰਮੇਵਾਰ ਖੋਜ-ਰਿਪੋਰਟਿੰਗ ਨਿਯਮ ਵੀ ਇੱਥੇ ਮਹੱਤਵਪੂਰਨ ਹਨ। ਰਿਪੋਰਟਰਾਂ ਨਾਲ ਰਟਾਈਮਰਾਸ਼ੀ ਕੋਆਰਡੀਨੇਟ ਕਰਨਾ, ਸਪਸ਼ਟ ਟਾਈਮਲਾਈਨਾਂ ਸੈੱਟ ਕਰਨਾ, ਅਤੇ ਖੋਜਕਾਰਾਂ ਨੂੰ ਕਰੈਡੀਟ ਦੇਣਾ ਮੱਦਦ ਕਰਦਾ ਹੈ ਕਿ ਫਿਕਸ ਆਯੋਜਿਤ ਢੰਗ ਨਾਲ ਹੋਣ ਅਤੇ ਹਰ ਮੁੱਦੇ ਨੂੰ ਸਿਰਫ਼ ਹੈੱਡਲਾਈਨ ਨਾ ਬਣਾਉਣ।\n\n### ਟੂਲਿੰਗ ਵਿੱਚ ਸਾਦਗੀ ਸਪਲਾਈ-ਚੇਨ ਗਲਤੀਆਂ ਘਟਾਉਂਦੀ ਹੈ\n\nਰਿਲੀਜ਼ ਇੰਜੀਨੀਅਰਿੰਗ ਵੀ ਜੋਖ਼ਮ ਪ੍ਰਬੰਧਨ ਹੈ। ਜਿੰਨਾ ਜ਼ਿਆਦਾ ਜਟਿਲ ਬਿਲਡ ਅਤੇ ਰਿਲੀਜ਼ ਚੇਨ ਹੋਵੇਗੀ, ਉਤਨੇ ਜ਼ਿਆਦਾ ਮੌਕੇ ਹੋਣਗੇ ਗਲਤ ਆਰਟੀਫੈਕਟ ਭੇਜਣ, ਗਲਤ ਸਾਈਨ ਕਰਨ ਜਾਂ ਨਿਰਭਰਤਾਵਾਂ ਦੇ ਸੰਕ੍ਰਮਣ ਲਈ।\n\nਇੱਕ ਸਧਾਰਨ, ਸਮਝਣਯੋਗ ਪਾਈਪਲਾਈਨ—ਦੁਹਰਾਏ ਯੋਗ ਬਿਲਡ, ਘੱਟ ਹਿਲਦੀ-ਡੁੱਲਦੀ ਚੀਜ਼ਾਂ, ਮਜ਼ਬੂਤ ਸਾਇਨਿੰਗ ਅਭਿਆਸ, ਅਤੇ ਸਿੱਧੀ ਪ੍ਰੋਵੇਨੈਂਸ—ਗਲਤ ਚੀਜ਼ ਭੇਜਣ ਦੇ ਮੌਕੇ ਘਟਾਉਂਦਾ ਹੈ।\n\n### ਡਰਾਬੇ ਬਿਨਾਂ ਜੋਖ਼ਮ ਦੀ ਸੂਚਨਾ ਦੇਣਾ\n\nਭੈ-ਭਰਪੂਰ ਸੰਦੇਸ਼ ਵਰਤੋਂਕਾਰਾਂ ਨੂੰ ਨੁਕਸਾਨ ਪਹੁੰਚਾ ਸਕਦਾ ਹੈ। ਸਪਸ਼ਟ ਭਾਸ਼ਾ ਵਰਤੋ, "ਰਿਮੋਟ", "ਲੋਕਲ" ਅਤੇ "ਪ੍ਰਿਵਿਲੇਜ ਐਸਕੇਲੇਸ਼ਨ" ਦਾ ਕੀ ਮਤਲਬ ਹੈ ਇਹ ਦੱਸੋ, ਅਤੇ ਅਣਿਸ਼ਚਿਤਤਾ ਬਾਰੇ ਸਚ ਬੋਲੋ। ਜਦੋਂ ਤੁਸੀਂ ਅਨੁਮਾਨ ਲਾਉਣੇ ਹੋ, ਉਹਨੂੰ ਲੇਬਲ ਕਰੋ।\n\nਇੱਕ "ਹੁਣ ਇਹ ਕਰੋ" ਰਾਹ (ਅਪਡੇਟ ਜਾਂ ਪੈਚ) ਅਤੇ ਇੱਕ "ਅਗਲਾ ਕਾਰਵਾਈ" ਰਾਹ (ਕੰਫਿਗ ਸਮੀਖਿਆ, ਮਾਨਿਟਰਿੰਗ) ਦਿਓ।\n\nਜਦ ਰਿਲੀਜ਼ ਪ੍ਰਕਿਰਿਆਵਾਂ, ਪੈਚਿੰਗ, ਅਤੇ ਸੰਚਾਰ ਇਕਰੂਪ ਹੁੰਦੇ ਹਨ, ਉਪਭੋਗਤਾ ਤੇਜ਼ੀ ਨਾਲ ਅਪਡੇਟ ਕਰਨਾ ਸਿੱਖ ਲੈਂਦੇ ਹਨ—ਅਤੇ ਇਹੀ ਥਾਂ ਹੈ ਜਿੱਥੇ ਡਿਫੌਲਟ-ਤੌਰ ਤੇ ਸੁਰੱਖਿਅਤ ਲੰਮੇ ਸਮੇਂ ਲਈ ਭਰੋਸਾ ਬਣਦਾ ਹੈ।\n\n## ਸੰਸਕ੍ਰਿਤੀ: ਉੱਚ ਮਿਆਰ, ਜ਼ਿੰਮੇਵਾਰੀ ਅਤੇ ਘਰਘਰਾਪਨ\n\nOpenBSD ਦੀ ਸੁਰੱਖਿਆ ਖ੍ਯਾਤੀ ਸਿਰਫ਼ ਚਤੁਰ ਮਿਟੀਗੇਸ਼ਨਾਂ ਬਾਰੇ ਨਹੀਂ—ਇਹ ਇਸ ਬਾਰੇ ਵੀ ਹੈ ਕਿ ਲੋਕ ਕਿਵੇਂ ਕੰਮ ਕਰਦੇ ਹਨ।\n\nਇਹ ਪ੍ਰੋਜੈਕਟ ਇਸ ਗੱਲ ਨੂੰ ਆਮ ਕੀਤਾ ਕਿ ਸੁਰੱਖਿਆ ਸਾਂਝੀ ਜ਼ਿੰਮੇਵਾਰੀ ਹੈ, ਅਤੇ ਕਿ "ਚੰਗਾ ਕਾਫ਼ੀ" ਡਿਫੌਲਟ (ਜਾਂ ਅਲਝਣ ਭਰੇ ਪੈਚ) ਸਿਰਫ਼ ਇਸ ਲਈ ਬਰਦਾਸ਼ਤ ਨਹੀਂ ਕੀਤੇ ਜਾਣੇ ਚਾਹੀਦੇ ਕਿ ਉਹ ਕੰਮ ਕਰਦੇ ਹਨ।\n\n### ਉਹ ਸੰਸਕ੍ਰਿਤਿਕ ਅੰਗ ਜੋ ਸੁਰੱਖਿਆ ਨੂੰ ਟਿਕਾਉਂਦੇ ਹਨ\n\nਕੁਝ ਆਦਤਾਂ ਜਿਹੜੀਆਂ ਸੁਰੱਖਿਆ-ਇੰਜੀਨੀਅਰਿੰਗ ਟੀਮਾਂ ਵਿੱਚ ਆਮ ਹਨ ਅਤੇ OpenBSD ਨੇ ਉਹਨਾਂ ਨੂੰ ਸਪਸ਼ਟ ਕੀਤਾ:\n\n- ਉੱਚ ਮਿਆਰ ਬੇਸਲਾਈਨ ਵਜੋਂ: ਕੋਡ ਪੜ੍ਹਨਯੋਗ, ਸੰਭਾਲੇ ਹੋਏ, ਅਤੇ ਸਭ ਤੋਂ ਵਧੀਆ ਅਰਥ ਵਿੱਚ "ਬੋਰਿੰਗ" ਉਮੀਦ ਕੀਤੀ ਜਾਂਦੀ ਹੈ।\n- ਠੋਸ ਫੀਡਬੈਕ ਅਤੇ ਸਪਸ਼ਟ ਮਲਕੀਅਤ: ਸਮੀਖਿਆਆਂ ਸਹੀਪਨ ਅਤੇ ਜੋਖ਼ਮ 'ਤੇ ਕੇਂਦਰਤ ਹੁੰਦੀਆਂ ਹਨ, ਨ ਕਿ ਨਿੱਜੀ ਪਸੰਦਾਂ 'ਤੇ।\n- ਸਾਂਝੀ ਜ਼ਿੰਮੇਵਾਰੀ: ਜੇ ਕੁਝ ਭੇਜਿਆ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਇਹ "ਸਾਡੀ" ਸਮੱਸਿਆ ਹੈ—ਸਮੀਖਿਆਕਾਰ ਅਤੇ ਮੇਨਟੇਨਰ ਨਤੀਜੇ ਦਾ ਹਿੱਸਾ ਹੁੰਦੇ ਹਨ।\n\n### ਜਦ ਮਜ਼ਬੂਤ ਰਾਏ ਮਦਦ ਕਰਦੇ ਹਨ—ਅਤੇ ਜਦ ਇਹ ਨੁਕਸਾਨ ਪਹੁੰਚਾਉਂਦੇ ਹਨ\n\nਮਜ਼ਬੂਤ ਰਾਏ ਸੁਰੱਖਿਆ ਨੂੰ ਬਚਾ ਕੇ ਰੱਖ ਸਕਦੇ ਹਨ ਕਿਉਂਕਿ ਖੇਡਾਂ-ਖੇਡ ਵਿੱਚ ਬੇਹਯਾਈ ਕਦਮ ਪਹਿਲਾਂ ਹੀ ਚੁਣੇ ਜਾਂਦੇ ਹਨ; ਜੋਖ਼ਮ ਭਰਪੂਰ ਛੋਟਕੀਆਂ ਪਹਿਲਾਂ ਹੀ ਚੁੱਕੀਆਂ ਜਾਂਦੀਆਂ ਹਨ, ਅਤੇ ਅਸਪਸ਼ਟ ਤਰਕਾਂ ("ਇਹ ਠੀਕ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ") ਨੂੰ ਇੱਕ ਬੱਗ ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ।\n\nਪਰ ਉਹੀ ਤੀਬਰਤਾ ਯੋਗਦਾਨ ਘਟਾ ਸਕਦੀ ਹੈ ਜੇ ਲੋਕ ਸਵਾਲ ਪੁੱਛਣ ਜਾਂ ਬਦਲਾਅ ਪੇਸ਼ ਕਰਨ ਵਿੱਚ ਅਸੁਰੱਖਿਅਤ ਮਹਿਸੂਸ ਕਰਣ। ਸੁਰੱਖਿਆ ਨੂੰ ਤਸ਼ਖੀਸ ਲਾਭ ਜਾਂਦਾ ਹੈ ਪਰ ਤਸ਼ਖੀਸ ਲਈ ਹਿੱਸਾ ਲੈਣਾ ਲਾਜ਼ਮੀ ਹੈ।\n\n### ਅੰਤਰਕਿਰਿਆ ਦਾ ਸਟਾਈਲ ਨਕਲ ਕੀਤੇ ਬਿਨਾਂ ਸਮੀਖਿਆ ਆਦਤਾਂ ਬਣਾਉ\n\nਤੁਸੀਂ ਇਕ ਮੰਗਲਾਤਮਕ ਸੰਸਕ੍ਰਿਤੀ ਦੀ ਯੰਤਰਨਾ ਉਧਾਰ ਲੈ ਸਕਦੇ ਹੋ ਬਿਨਾਂ ਉਸ ਦੇ ਅੰਤਰਕਥਨੀ ਅੰਦਾਜ਼ ਨੂੰ ਨਕਲ ਕੀਤੇ।\n\nਕਈ ਪ੍ਰਯੋਗਿਕ ਰਸਮਾਂ ਜੋ ਵੱਧਤਰ ਸੰਸਥਾਵਾਂ ਵਿੱਚ ਕੰਮ ਕਰਦੀਆਂ ਹਨ:\n\n- ਪ੍ਰੀ-ਮਰਜ ਗੇਟ: ਸੁਰੱਖਿਆ-ਸੰਵੇਦਨਸ਼ੀਲ ਖੇਤਰਾਂ (auth, parsing, crypto, networking) ਲਈ ਘੱਟੋ-ਘੱਟ ਇੱਕ ਸਵਤੰਤਰ ਸਮੀਖਿਆ ਦੀ ਲੋੜ ਰੱਖੋ।\n- ਸਮੀਖਿਆ ਰੋਟੇਸ਼ਨ: ਇੱਕ ਸਪਤਾਹਿਕ "ਰੀਵਿਊ ਕੈਪਟਨ" ਨਿਯੁਕਤ ਕਰੋ ਤਾਂ ਕਿ ਕਤਾਰਾਂ ਹਿਲਦੀਆਂ ਰਹਿਣ ਅਤੇ ਗਿਆਨ ਫੈਲਦਾ ਰਹੇ।\n- ਹਲਕੀ-ਫ਼ੁਲਕੀ ਚੈਕਲਿਸਟ: ਇੱਕ ਛੋਟੀ, ਲਗਾਤਾਰ ਸੂਚੀ (ਇਨਪੁੱਟ ਵੈਲिडੇਸ਼ਨ, ਐਰਰ ਹੈਂਡਲਿੰਗ, ਪ੍ਰਿਵਿਲੇਜ ਸੀਮਾਵਾਂ, ਲੌਗਿੰਗ) ਹਰ PR ਨਾਲ ਸੰਲਗਨ ਕਰੋ।\n- "ਰਿਸਕ ਸਮਝਾਓ" ਟਿੱਪਣੀਆਂ: ਸਮੀਖਿਆਕਾਰ ਡਿਫੌਲਟਸ ਜਾਂ ਭਰੋਸੇ ਦੀਆਂ ਸੀਮਾਵਾਂ ਬਦਲਣ 'ਤੇ ਇੱਕ-ਪੈਰਾ ਰਿਸਕ ਸੰਖੇਪ ਮੰਗਦੇ ਹਨ।\n\nਨਿਸ਼ਕਰਸ਼: ਸੁਰੱਖਿਆ ਕੋਈ ਫੀਚਰ ਨਹੀਂ ਜੋ ਤੁਸੀਂ ਬਾਅਦ ਵਿੱਚ ਜੋੜਦੇ ਹੋ। ਇਹ ਇੱਕ ਮਿਆਰ ਹੈ ਜੋ ਤੁਸੀਂ ਲਗਾਤਾਰ, ਵਿਸ਼ੇਸ਼ ਤੌਰ 'ਤੇ ਲਾਗੂ ਕਰਦੇ ਹੋ—ਉਹ ਪ੍ਰਕਿਰਿਆ ਜੋ ਸਹੀ ਚੋਣ ਨੂੰ ਸਭ ਤੋਂ ਆਸਾਨ ਬਣਾਉਂਦੀ ਹੈ।\n\n## ਅਧੁਨਿਕ ਸਿਸਟਮਾਂ 'ਤੇ OpenBSD ਦੇ ਸਬਕ ਲਾਗੂ ਕਰਨ ਦੇ ਢੰਗ\n\nOpenBSD ਦਾ ਸਭ ਤੋਂ ਵੱਡਾ ਟ੍ਰਾਂਸਫਰੇਬਲ ਵਿਚਾਰ ਕਿਸੇ ਖਾਸ ਟੂਲ ਵਿੱਚ ਨਹੀਂ—ਇਹ ਆਦਤ ਹੈ ਕਿ ਡਿਫੌਲਟਸ ਨੂੰ ਤੁਹਾਡੇ ਸੁਰੱਖਿਆ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਦਾ ਹਿੱਸਾ ਸਮਝੋ।\n\nਤੁਸੀਂ ਉਹ ਮਨੋਵਿਗਿਆਨ ਕਿਸੇ ਵੀ ਥਾਂ ਲਾਗੂ ਕਰ ਸਕਦੇ ਹੋ ਜੇ ਤੁਸੀਂ "ਡਿਫੌਲਟ-ਤੌਰ ਤੇ ਸੁਰੱਖਿਅਤ" ਨੂੰ ਉਹਨਾਂ ਵਿਹਾਰਾਂ ਵਿੱਚ ਰੂਪਾਂਤਰਿਤ ਕਰੋ ਜੋ ਤੁਹਾਡੀ ਸੰਸਥਾ ਵਾਰਡ-ਵਾਰ ਕਰਦਾ ਹੈ, ਨਾ ਕਿ ਇੱਕ ਘਟਨਾ ਦੇ ਬਾਅਦ ਹੀ ਹੀਰੋइਕ ਕੰਮ।\n\n### ਨੀਤੀਆਂ ਨੂੰ ਅਜਿਹੇ ਨੀਤੀਆਂ ਵਿੱਚ ਬਦਲੋ (ਜੋ ਟੀਮਾਂ ਪਾਲਣ ਸਕਣ)\n\nਦੋ ਛੋਟੀਆਂ ਨੀਤੀਆਂ ਲਿਖ ਕੇ ਸ਼ੁਰੂ ਕਰੋ ਜੋ ਆਡੀਟ ਕਰਨਾ ਆਸਾਨ ਹੋਣ:

• ਸੁਰੱਖਿਅਤ ਬੇਸਲਾਈਨ ਨੀਤੀ: ਨਵੀਆਂ ਸੇਵਾਵਾਂ ਅਤੇ ਹੋਸਟਾਂ ਨੂੰ منظورਸ਼ੁਦਾ ਬੇਸਲਾਈਨ ਤੋਂ ਸ਼ੁਰੂ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ (ਪੋਰਟ ਬੰਦ, ਲੈਸਟ-ਪ੍ਰਿਵਿਲੇਜ, ਲੌਗਿੰਗ ਚਾਲੂ, ਅਪਡੇਟਸ ਐਨੇਬਲ)। ਛੂਟਾਂ ਲਈ ਸਪਸ਼ਟ ਮਲਕੀਅਤ ਅਤੇ ਸਮਾਪਤੀ ਤਾਰੀਖ ਲਾਜ਼ਮੀ ਹੋ।
• ਐਕਸਪੋਜ਼ਰ ਬਦਲਾਅ ਨੀਤੀ: ਜੋ ਕੁਝ ਵੀ ਐਕਸਪੋਜ਼ਰ ਵਧਾਉਂਦਾ ਹੈ (inbound ਪੋਰਟ ਖੋਲ੍ਹਣਾ, ਪਬਲਿਕ ਬੱਕਟ, IAM ਰੋਲ ਵੱਡੀ ਕਰਨਾ) ਉਸਦੇ ਲਈ ਸਮੀਖਿਆ ਲਾਜ਼ਮੀ ਹੈ ਅਤੇ ਇਹਨੂੰ ਸੁਰੱਖਿਆ-ਸੰਬੰਧੀ ਬਦਲਾਅ ਵਜੋਂ ਟਰੈਕ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।

ਇਹ ਤਰੀਕਾ "ਹਾਰਡਨ ਕਰਨ ਨੂੰ ਯਾਦ ਰੱਖੋ" ਦੇ ਬਦਲੇ "ਇਹ ਹਾਰਡਨ ਹੋ ਕੇ ਭੇਜਿਆ ਜਾਂਦਾ ਹੈ ਜਦ ਤੱਕ ਕੋਈ ਕਿਸੀ ਜੋਖ਼ਮ ਲਈ ਸਾਈਨ ਨਾ ਕਰੇ" ਨੂੰ ਲਾਗੂ ਕਰਦਾ ਹੈ।\n\n### ਇੱਕ ਪ੍ਰਯੋਗਿਕ "ਸੁਰੱਖਿਅਤ ਬੇਸਲਾਈਨ" ਚੈਕਲਿਸਟ\n\nਇਨਪੋਇੰਟਸ ਅਤੇ ਸੇਵਾਵਾਂ ਲਈ ਇਹ ਇੱਕ ਸ਼ੁਰੂਆਤੀ ਸੂਚੀ ਹੈ:\n\n- ਬਿਨਾਂ ਵਰਤੋਂ ਵਾਲੀਆਂ ਸੇਵਾਵਾਂ, ਏਜੰਟ ਅਤੇ ਪੈਕੇਜ ਅਣਇੰਸਟਾਲ/ਅਸਥਗਿਤ ਕਰੋ। ਜੇ ਲੋੜ ਨਹੀਂ, ਤਾਂ ਇਹ ਸੁਣਨਾ ਨਹੀਂ ਚਾਹੀਦਾ।\n- ਹੋਸਟ ਫਾਇਰਵਾਲ ਚਾਲੂ; inbound ਸਿਰਫ਼ ਲੋੜੀਂਦੇ ਪੋਰਟ ਅਤੇ ਸਰੋਤਾਂ ਲਈ ਆਗਿਆ।\n- ਸੇਵਾ ਖਾਤਿਆਂ ਨੂੰ ਵੱਖ-ਵੱਖ ਰੱਖੋ; ਕੋਈ ਸਾਂਝਾ ਐਡਮਿਨ ਯੂਜ਼ਰ ਨਾ ਹੋਵੇ; ਲੰਬੀ Avadhi ਵਾਲੇ Access keys ਨਾ ਹੋਣ।\n- ਕੰਪੋਨੇਟਾਂ ਨੂੰ ਵੱਖ-ਵੱਖ ਪਹਚਾਣ ਨਾਲ ਚਲਾਓ; systemd sandboxing, ਕਾਂਟੇਨਰ ਜਾਂ ਵੱਖ-ਵੱਖ ਨਾਡਾਂ ਨਾਲ ਅਲੱਗ ਕਰੋ।\n- ਜਿੱਥੇ ਹੋ ਸਕੇ ਆਟੋਮੈਟਿਕ ਸੁਰੱਖਿਆ ਅਪਡੇਟ; ਨਾ ਹੋਵੇ ਤਾਂ ਸਪਸ਼ਟ ਮੈਂਟੇਨੈਂਸ ਵਿੰਡੋਜ਼।\n- ਸੈਂਟਰਲ ਲੌਗ, ਟਾਈਮ ਸਿੰਕ, ਅਤੇ ਘੱਟੋ-ਘੱਟ ਸੁਰੱਖਿਆ ਇਵੈਂਟ (ਪਰਮਾਣੀਕਰਨ, ਪ੍ਰਿਵਿਲੇਜ ਬਦਲਾਅ, ਨੈੱਟਵਰਕ ਨੀਤੀ ਬਦਲਾਅ)।\n- ਵਰਜਨ-ਕੰਟਰੋਲਡ ਕੰફਿਗ (IaC) ਨਾਲ, ਪੀਅਰ ਰਿਵਿਊ ਅਤੇ ਲਿੰਟਿੰਗ।\n\n### ਮੈਟ੍ਰਿਕਸ ਜੋ ਦਰਸਾਉਂਦੇ ਹਨ ਕਿ ਤੁਹਾਡੇ ਡਿਫੌਲਟ ਸੁੱਧਰ ਰਹੇ ਹਨ\n\nਕੁਝ ਐਸੇ ਨੰਬਰ ਚੁਣੋ ਜੋ ਗੇਮ ਕਰਨ ਮੁਸ਼ਕਲ ਹੋਣ: \n- ਜਨਤਕ ਤੌਰ 'ਤੇ ਪਹੁੰਚਯੋਗ ਸੇਵਾਵਾਂ/ਪੋਰਟਾਂ ਦੀ ਗਿਣਤੀ (ਟਰੇਂਡ ਘਟ ਰਿਹਾ ਹੋਵੇ)।\n- ਸੁਰੱਖਿਆ ਅਪਡੇਟ ਰਿਲੀਜ਼ ਤੋਂ ਡਿਪਲੋਏ ਕਰਨ ਤੱਕ ਦਾ ਮੈਡੀਅਨ ਸਮਾਂ।\n- ਵਿਸਥਾਪਨ ਲੱਭੀਆਂ ਗਿਣਤੀਆਂ ਜਿਵੇਂ ਵਰਲਡ-ਰਾਈਟੇਬਲ ਫਾਇਲਾਂ, ਜ਼ਿਆਦਾ ਵਿਸ਼ਤਾਰਤ IAM ਰੋਲ, ਅਨੋਨਿਮੱਸ ਸਟੋਰੇਜ ਐਕਸੈਸ, ਜਾਂ TLS-disable ਕੀਤੀਆਂ ਸੈਟਿੰਗਾਂ ਦੀ ਗਿਣਤੀ।\n\n### ਇਹ ਮਨੋਵਿਗਿਆਨ ਅਧੁਨਿਕ "vibe coding" ਵਰਕਫਲੋਜ਼ ਵਿੱਚ ਕਿੱਥੇ ਫਿੱਟ ਹੁੰਦੀ ਹੈ\n\nਤੇਜ਼ ਬਿਲਡ ਚੱਕਰ ਸੁਰੱਖਿਆ ਨੂੰ ਸੁਧਾਰ ਸਕਦੇ ਹਨ (ਕਿਉਂਕਿ ਫਿਕਸ ਤੇਜ਼ੀ ਨਾਲ ਭੇਜੇ ਜਾਂਦੇ ਹਨ) ਜਾਂ ਜੋਖ਼ਮ ਨੂੰ ਤੀਜ਼ੀ ਨਾਲ ਵਧਾ ਸਕਦੇ ਹਨ (ਕਿਉਂਕਿ ਅਸੁਰੱਖਿਅਤ ਡਿਫੌਲਟ ਤੇਜ਼ੀ ਨਾਲ ਨਕਲ ਹੋ ਜਾਂਦੇ ਹਨ)। ਜੇ ਤੁਸੀਂ LLM-ਸਹਾਇਤ ਵਰਕਫਲੋ ਵਰਤ ਰਹੇ ਹੋ, ਤਾਂ "ਡਿਫੌਲਟ-ਤੌਰ ਤੇ ਸੁਰੱਖਿਅਤ" ਨੂੰ ਇੱਕ ਪ੍ਰੋਡਕਟ ਲੋੜ ਦੇ ਤੌਰ 'ਤੇ ਯਕੀਨੀ ਬਣਾਓ—ਬਾਅਦ ਦੀ ਗੱਲ ਨਹੀਂ।\n\nਉਦਾਹਰਨ ਲਈ, ਜਦੋਂ apps Koder.ai 'ਤੇ ਬਣ ਰਹੇ ਹਨ (ਇੱਕ vibe-coding ਪਲੇਟਫਾਰਮ ਜੋ ਚੈਟ ਤੋਂ ਵੈੱਬ, ਬੈਕਐਂਡ ਅਤੇ ਮੋਬਾਈਲ ਐਪ ਬਣਾਉਂਦਾ ਹੈ), ਤੁਸੀਂ OpenBSD ਸਬਕ ਲਾਗੂ ਕਰ ਸਕਦੇ ਹੋ ਬੇਸਲਾਈਨ ਨੂੰ ਪਹਿਲਾਂ ਹੀ ਸਪਸ਼ਟ ਕਰਕੇ: ਲੈਸਟ-ਪ੍ਰਿਵਿਲੇਜ ਰੋਲ, ਡਿਫੌਲਟ ਪ੍ਰਾਈਵੇਟ ਨੈੱਟਵਰਕਿੰਗ, ਅਤੇ ਸੰਯਮਿਤ ਕੰਫਿਗ ਟੈਂਪਲੇਟ। Koder.ai ਦਾ ਸ਼ੁਰੂ ਵਿੱਚ ਉਹ ਸਖ਼ਤੀ ਲਿਆਉਣ ਲਈ ਠੀਕ ਥਾਂ ਹੈ—ਖਤਰੇ ਦੀਆਂ ਹੱਦਾਂ ਅਤੇ ਡਿਫੌਲਟ ਐਕਸਪੋਜ਼ਰ ਨੂੰ Implementation ਤੋਂ ਪਹਿਲਾਂ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ।\n\nਆਪਰੇਸ਼ਨਲੀ ਤੌਰ 'ਤੇ, ਵਰਗੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਡਿਪਲੋਅਮੈਂਟ ਪੱਧਰ 'ਤੇ "ਡਿਫ਼ੈਂਸ-ਇਨ-ਡੈਪਥ" ਨੂੰ ਮਜ਼ਬੂਤ ਕਰਦੀਆਂ ਹਨ: ਜਦੋਂ ਕੋਈ ਬਦਲਾਅ ਗਲਤੀ ਨਾਲ ਐਕਸਪੋਜ਼ਰ ਵਧਾ ਦੇਵੇ, ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਵਾਪਸ ਜਾ ਸਕਦੇ ਹੋ, ਫ਼ਿਰ ਸਹੀ ਡਿਫੌਲਟ ਸ਼ਿਪ ਕਰ ਸਕਦੇ ਹੋ। ਅਤੇ ਕਿਉਂਕਿ Koder.ai ਸਪੋਰਟ ਕਰਦਾ ਹੈ, ਤੁਸੀਂ ਜਨਰੇਟ ਕੀਤੇ ਕੋਡ ਨੂੰ ਹੋਰ ਕਿਸੇ ਵੀ ਪ੍ਰੋਡਕਸ਼ਨ ਕੋਡ ਵਾਂਗ ਇੰਟੇਨਸ਼ਨ ਨਾਲ ਆਡੀਟ ਕਰ ਸਕਦੇ ਹੋ: ਜਨਰੇਟ ਕੀਤਾ ਕੋਡ ਵੀ ਰਿਵਿਊ, ਟੈਸਟ ਅਤੇ ہਾਰਡਨ ਕਰੋ।\n\n## ਆਮ ਗ਼ਲਤਫਹਮੀਆਂ ਅਤੇ ਇਕ ਸੰਤુલਿਤ ਨਤੀਜਾ\n\n"ਡਿਫੌਲਟ-ਤੌਰ ਤੇ ਸੁਰੱਖਿਅਤ" ਬਹੁਤ ਵਾਰੀ ਦੁਹਰਾਇਆ ਜਾਂਦਾ ਹੈ, ਪਰ ਇਹ ਸਮਝਣਾ ਆਸਾਨ ਹੈ ਕਿ OpenBSD (ਅਤੇ ਥੀਓ ਦੇ ਰਾਟਡ ਦੀ ਵਿਆਪਕ ਫਿਲਾਸਫੀ) ਨੇ ਅਸਲ ਵਿੱਚ ਕੀ ਦਰਸਾਇਆ।\n\n### ਗਲਤ ਫ਼ੈਮੀ #1: "ਡਿਫੌਲਟ-ਤੌਰ ਤੇ ਸੁਰੱਖਿਅਤ" ਦਾ ਮਤਲਬ ਅਟੂਟ ਹੈ\n\nਇਹ ਨਹੀਂ ਹੈ। ਕੋਈ ਵੀ ਜਨਰਲ-ਪਰਾਫ਼ੇਸ OS "ਹੈੱਕ ਨਹੀਂ ਹੋ ਸਕਦਾ" ਦਾ ਵਾਅਦਾ ਨਹੀਂ ਦੇ ਸਕਦੀ। ਅਸਲ ਦਾਅਵਾ ਪਹਿਲੇ-ਹਵਾਲੇ ਦਾ ਹੈ: ਇੱਕ ਤਾਜ਼ਾ ਇੰਸਟਾਲ ਰੱਖਿਆਯੋਗ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ—ਘੱਟ ਜੋਖ਼ਿਮ ਵਾਲੀਆਂ ਸੇਵਾਵਾਂ, ਸੁਰੱਖਿਅਤ ਡਿਫੌਲਟ, ਅਤੇ ਉਹ ਫੀਚਰ ਜੋ ਕੁਝ ਗਲਤ ਹੋਣ 'ਤੇ ਬਲਾਸਟ-ਰੇਡੀਅਸ ਘਟਾਉਂਦੇ ਹਨ।\n\nਇਹ ਮਨੋਵਿਗਿਆਨ 生命周期 ਦੇ ਸ਼ੁਰੂ ਵਿੱਚ ਕੰਮ ਨੂੰ ਅੱਗੇ ਧੱਕਦਾ ਹੈ। ਯੂਜ਼ਰਾਂ ਨੂੰ ਅਣਸੁਰੱਖਿਅਤ ਸੈਟਿੰਗਾਂ ਲੱਭ ਕੇ ਠੀਕ ਕਰਨ ਦੀ ਥਾਂ, ਸਿਸਟਮ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ ਕਿ ਸੁਰੱਖਿਅਤ ਚੋਣ ਉਨ੍ਹਾਂ ਲਈ ਸਭ ਤੋਂ ਆਸਾਨ ਰਾਹ ਹੋਵੇ।\n\n### ਗਲਤ ਫ਼ੈਮੀ #2: ਸੁਰੱਖਿਆ "ਮੁਫ਼ਤ" ਹੈ ਅਤੇ UX 'ਤੇ ਕਦੇ ਵੀ ਅਸਰ ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ\n\nਸੁਰੱਖਿਆ ਡਿਫੌਲਟਾਂ ਦੀ ਕੀਮਤ ਹੋ ਸਕਦੀ ਹੈ: ਸੁਵਿਧਾ, ਅਨੁਕੂਲਤਾ, ਜਾਂ ਪ੍ਰਦਰਸ਼ਨ। ਇੱਕ ਲੈਗੇਸੀ ਫੀਚਰ ਨੂੰ ਅਣ-ਯੋਗ ਕਰਨਾ, ਅਧਿਕਾਰਾਂ ਤੰਗ ਕਰਨਾ, ਜਾਂ ਸਖ਼ਤ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫਿਕ ਚੋਣਾਂ ਲਗਾਉਣਾ ਕਿਸੇ ਨੂੰ ਉਭਾਰ ਸਕਦਾ ਹੈ ਜੋ ਪੁਰਾਣੇ ਵਿਵਹਾਰ 'ਤੇ ਨਿਰਭਰ ਸੀ।\n\nOpenBSD ਦਾ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਮਨਾਊਂਦਾ ਹੈ ਕਿ ਕੁਝ ਘਰਜੀ ਰੁਕਾਵਟ ਕਬੂਲਯੋਗ ਹਨ ਜੇ ਇਹ ਚੁਪਚਾਪ, ਵਿਆਪਕ ਐਕਸਪੋਜ਼ਰ ਨੂੰ ਰੋਕਦੇ ਹਨ। ਵਪਾਰ-ਅਧਿਕਾਰ ਪ੍ਰਭੇਦ "ਸੁਰੱਖਿਆ ਬਣਾਮ ਯੂਜ਼ਬਿਲਿਟੀ" ਨਹੀਂ, ਪਰ "ਕੌਣ ਭਾਰ ਝੇਲਦਾ ਹੈ": ਹਰ ਉਪਭੋਗੀ ਡਿਫੌਲਟ ਨਾਲ, ਜਾਂ ਉਹ ਗਿਣਤੀ ਜੋ ਅਸਲ ਵਿੱਚ ਘਟਾਣੇ ਸਕਦੀ ਹੈ।\n\n### ਗਲਤ ਫ਼ੈਮੀ #3: ਤੁਸੀਂ ਸੈਟਿੰਗਾਂ ਨਕਲ ਕਰਕੇ ਉਹੀ ਨਤੀਜੇ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦੇ ਹੋ\n\nਕੈਂਰਗੋ-ਕਲੁਟ ਸੁਰੱਖਿਆ—ਕੰਫਿਗ ਸਨੀਪੇਟ ਬਿਨਾਂ ਧੋਖਾ-ਮਾਡਲ, ਡਿਪਲੋਇਮੈਂਟ ਸੰਦਰਭ, ਅਤੇ ਆਪਰੇਸ਼ਨਲ ਸੀਮਾਵਾਂ ਸਮਝਦੇ ਹੋਏ ਓਠਣਾ—ਅਕਸਰ ਨਾਜ਼ੁਕ ਸਿਸਟਮ ਬਣਾਉਂਦਾ ਹੈ। ਇੱਕ ਹਾਰਡਨਿੰਗ ਫਲੈਗ ਜੋ ਇਕ ਪਲੇਟਫਾਰਮ 'ਤੇ ਮਦਦ ਕਰਦਾ ਹੈ ਉਹ ਅਪਡੇਟ, ਮਾਨੀਟਰਨਿੰਗ, ਜਾਂ ਰਿਕਵਰੀ ਪ੍ਰਕਿਰਿਆਵਾਂ ਨੂੰ ਟੁੱਟਾ ਦੇ ਸਕਦਾ ਹੈ।\n\nਗਹਿਰਾ ਸਬਕ ਢੰਗ ਹੈ: ਧਿਆਨਪੂਰਨ ਡਿਫੌਲਟ, ਲਗਾਤਾਰ ਸਮੀਖਿਆ, ਅਤੇ ਰਿਸਕ-ਭਰੀ ਵਿਵਹਾਰ ਨੂੰ ਹਟਾਉਣ ਦੀ ਤਿਆਰੀ—ਚਾਹੇ ਉਹ ਲੋਕਪ੍ਰਿਯ ਹੋਵੇ—ਜੋ ਵਧੇਰੇ ਕੀਮਤੀ ਹੈ।\n\n### ਇਕ ਸੰਤੁਲਿਤ ਨਤੀਜਾ\n\nOpenBSD ਦਾ ਪ੍ਰਭਾਵ ਹਕੀਕਤ ਵਿੱਚ ਮਹੱਤਵਪੂਰਨ ਹੈ: ਆਧੁਨਿਕ ਹਾਰਡਨਿੰਗ, ਆਡੀਟ ਆਦਤਾਂ, ਅਤੇ "ਡਿਫੌਲਟ-ਤੌਰ ਤੇ ਸੁਰੱਖਿਅਤ" ਉਮੀਦਾਂ ਲਈ ਕਾਫ਼ੀ ਯੋਗਦਾਨ ਕਿੱਤਾ ਹੈ।\n\nਪਰ ਸਭ ਤੋਂ ਵੱਡਾ ਯੋਗਦਾਨ ਸੰਸਕ੍ਰਿਤਿਕ ਹੋ ਸਕਦਾ ਹੈ—ਸੁਰੱਖਿਆ ਨੂੰ ਇੱਕ ਇੰਜੀਨੀਅਰਿੰਗ ਵਿਗਿਆਨ ਵਜੋਂ ਦੇਖਣਾ: ਮਿਆਰ, ਰੱਖ-ਰਖਾਵ, ਅਤੇ ਜ਼ਿੰਮੇਵਾਰੀ, ਨਾ ਕਿ ਕੇਵਲ ਨੋਬ ਦੀ ਸ਼੍ਰੇਣੀ।