1,646 測定値

Web プロジェクトを作成する前に自問すべき 5 つの質問

に Filipp Shcherbanich9m2024/08/01

長すぎる; 読むには

Web プロジェクトが失敗する理由はさまざまです。この記事では、いくつかの問題を解決するのに役立つ私の経験を共有します。

featured image - Web プロジェクトを作成する前に自問すべき 5 つの質問

技術プロジェクトが失敗する理由は無数にあります。ビジネスモデルの計算ミス、需要の過大評価、コストの高騰など、挙げればきりがありません。しかし、私はこれまでの職業生活で、素晴らしいアイデアと大きな可能性を秘めたプロジェクトが、一見些細な間違いや見落としで崩壊するのを何度も見てきました。そして、少なくとも開発者である私にとっては、これが最も辛い理由だと思います。この記事では、私の経験を共有し、Web アプリケーションに取り組むバックエンド開発者が直面する問題と課題を分析したいと思います。見落とされがちな重要なポイントを強調し、これらの障害に最大限効率的に対処する方法を説明します。これにより、リスクを最小限に抑え、プロジェクトが成功する可能性を大幅に高めることができると確信しています。

1. コード内に秘密が保存されていますか?

いかに明白に聞こえるとしても、この点は重要です。ソースコードに機密情報やセンシティブな情報を決して保存しないでください。違反は金銭的損失やその他の深刻な問題につながる可能性があります。コードに保存してはならないセンシティブな情報には、次のものがあります。

内部または外部サービスへのAPIキーとアクセストークン
パスワードとアカウントデータ（データベースと管理システムのパスワードを含む）
暗号化キー
機密データを含む設定ファイル
母親の旧姓やペットの名前などのセキュリティに関する質問への回答

このような情報をプロジェクトコードに保存する代わりに、環境変数を使用してください。より安全なシステムのために、次のような堅牢な秘密ストレージソリューションの使用を検討してください。ハシコープボールト。 AWS シークレットマネージャーまたはGitHub の秘密も役立ちます。秘密保管ツールの選択は、プロジェクトの種類と規模、チームの経験、テクノロジースタックなどの要素によって異なります。

アプリケーションコードに機密情報を保存することは大した問題ではないと思うなら、次のことを考えてみてください。2022年だけでも、GitHubは170万以上の潜在的な秘密パブリックリポジトリで公開されています。開発者が漏洩の可能性に気付かないプライベートプロジェクトでは、このようなデータがどれだけ存在するか想像してみてください。

解決策: 今すぐプロジェクトを確認してください

すでにプロジェクトがあり、コード内の秘密が心配な場合は、安心できる便利なソリューションがあります。手動チェックは時間がかかることがあるため、自動化が鍵となります。便利なツールには次のものがあります。

トリュフホッグ: API キーやその他の機密データのコミット履歴をスキャンして、Git リポジトリ内のシークレットを検索します。
ギットリークス: Git リポジトリ内のパスワード、API キー、トークンなどのハードコードされたシークレットを検出します。
ギットガーディアン: ローカルまたは CI 環境で動作し、350 種類を超えるシークレットやその他のセキュリティ脆弱性を検出します。
GitHub 高度なセキュリティ: リポジトリを自動的にスキャンして既知のタイプのシークレットを探し、見つかった場合は警告します。

これらのツールはほんの一例です。他の人気のオプションとしては、ソナーキューブそしてチェックマークスどちらも、さまざまなニーズと予算に合わせて有料および無料のソリューションを提供しています。ここでの目標は、利用可能なすべてのツールをリストすることではなく、これらの問題の存在と潜在的な解決策を強調することです。問題を認識することは、戦いの半分です。次に、問題に対処するために時間を割り当て、ニーズに適したツールを選択することが重要です。

2. ライブラリのライセンスについて何を知っていますか?

驚くべきことに、この話題はほとんど議論されておらず、サードパーティのソリューションを使用すると法的問題や会社にとって重大な問題が発生する可能性があることに気付いていない開発者もいます。信じられないですか？次のシナリオを想像してみてください。小さな会社の開発者が、 GNU アフェロ一般公衆利用許諾書 (AGPL)商用 Web 製品では、AGPL はコピーレフトライセンスであるため、AGPL でリリースされたコードを使用するすべてのソフトウェアを同じ条件で配布する必要があります。つまり、独自の開発を含むすべての Web アプリケーションのコードは、オープンで、自由に使用および変更できるようにする必要があります。このサンプル製品は商用であるため、ソースコードを公開すると、会社の競争上の優位性とビジネスモデルが著しく損なわれる可能性があります。

商用利用を明示的に禁止するライセンスを持つライブラリを使用するプロジェクトでも、深刻な問題が発生する可能性があります。ライセンスがまったくない場合、状況はそれほど改善されません。実際、コードはデフォルトで著作権で保護されているため、ライセンスがないと重大な問題が生じます。ライセンスは、特定の条件下でコードを使用する権利をユーザーに付与しますが、ライセンスがなければ、コードが一般に公開されている場合でも、コードを使用する法的根拠はまったくありません。

ライセンスの問題は、管轄地域によってさまざまな形で影響する可能性があることに留意してください。この問題は、国際的な著作権協定を締結している国に特に関係します。たとえば、この分野の主要な国際条約の 1 つである文学的および美術的著作物の保護に関するベルヌ条約には、現在約 180 か国が加盟しています。したがって、明示的な許可なしにコードを使用することは著作権法に違反することを意味し、世界中の多くの場所で法廷闘争につながる可能性があります。ただし、これは、すべての明文化および暗黙のルールに違反するためだけに「快適な」国に移住する必要があるという意味ではありません。お互いを尊重しましょう。誰かが自分の開発を特定の目的で使用したくない場合は、人間的な観点からもそうしないのが最善です。

解決策: 自動チェックと更新を使用する

ご覧のとおり、ライセンスと著作権の問題は複雑です。自分自身と会社を事前に保護するには、使用するライブラリとソフトウェアのライセンスを確認することをお勧めします。ライブラリの場合、これはそれほど難しくありません。最新のパッケージマネージャーにはすでにそのためのツールがあります。たとえば、PHP Composerでは、` コマンドでこれを行うことができます。作曲家ライセンス`、Pythonのpipでは` pip ライセンス` で、Golangでは ` を通じてこの情報を取得できます。ゴーライセンス`。

また、依存関係を更新するときにこれらのコマンドを呼び出すことを忘れないでください (これらのチェックを自動化するとさらに良いです)。接続されたライブラリのライセンスは新しいバージョンで変更される可能性があるためです。

3. 開発バージョンへのアクセスは制限されていますか?

Web 開発では、開発 (dev)、品質保証 (QA)、ステージング、本番など、プロジェクトに複数のバージョンがあることが一般的です。サイトまたは Web プロジェクトの開発/QA およびステージングバージョンがインターネット上の誰でもアクセスできるというシナリオに頻繁に遭遇しました。驚くべきことに、テストバージョンはプライマリバージョンよりも効果的に検索エンジンにインデックス付けされる場合があり、通常は製品に悪影響を及ぼします。

ここでの主な問題は、テストバージョンにはバグや機密情報、場合によっては危険情報が含まれている可能性があることです。さらに、ベータバージョンは通常、最終製品よりもハッキングに対して脆弱です。つまり、ベータバージョンを公開すると、攻撃者が機密データ、内部コード、さらにはサーバー自体にアクセスするリスクが高まります。モバイルアプリケーションなどのバックエンドを開発している場合は特にそうです。API のテストバージョンへの不正アクセスは非常に危険です。

セキュリティ上のリスク以外にも、重複した Web ページは検索エンジンのランキングに悪影響を及ぼす可能性があります。Google などの検索エンジンは、これらの重複を望ましくないコンテンツと見なす可能性があり、プロジェクトの元のページのランキングが下がったり、インデックスから完全に削除されたりする可能性があります。

解決策: 最初からセキュリティ戦略を策定する

ドメインをケチらないでください。オンラインでアクセス可能なテストバージョンが必要な場合は、専用の別のドメインを購入してください。このシンプルですが効果的な対策により、攻撃者は通常サブドメインを最初にチェックするため、セキュリティリスクが軽減されます。テストバージョンをメインリソースのサブドメインにホストすると、簡単に攻撃対象になってしまいます。

すべてのテストバージョンへのアクセスを制限します。開発、QA、ステージング、およびその他のバージョンがパブリックにアクセスできないようにします。たとえば、VPN 経由でのみアクセスできるように構成します。これにより、テストドメインが悪意のある行為者に知られることがあっても、不正アクセスの可能性が減ります。

テストバージョンがインデックスに登録されないように保護します。テストバージョンが VPN 経由でのみアクセス可能で、別の秘密ドメインでホストされている場合でも、`robots.txt` ファイルまたは `noindex` メタタグを使用して、検索エンジンによるインデックス登録から保護します。検索エンジンは予期しない方法でこれらのページを見つけてインデックス登録することがあるため、この手順は非常に重要です。

4. 実際の IP アドレスは隠されていますか? 使用していないポートは閉じられていますか?

セキュリティルールの中には、非常に重要で、苦労して学んだ教訓から確立されたものであっても、多くの開発者が見落としがちなものがあります。そのようなルールの 1 つは、プロジェクトの実際の IP アドレスを常に隠すことです。ドメイン名からサーバーの IP アドレスを特定できると、次のようないくつかの問題が発生する可能性があります。

DDoS攻撃: プロジェクトの実際のIPアドレスを知っている攻撃者は、サーバーに対して分散型サービス拒否（DDoS）攻撃を仕掛けることができます。たとえば、 DNS リフレクション増幅攻撃により、パブリック DNS サーバーからの大量の応答によってサーバーが圧倒され、ユーザーがサービスを利用できなくなり、多大な経済的損失が発生する可能性があります。
潜在的な脆弱性の特定: アマチュアだけでなく、本格的なハッカーは、開いているポートやネットワークに公開されているソフトウェアをスキャンして、弱点を見つけて悪用することができます。MongoDB のような有名なサービスでさえ、誤った構成が原因で重大なデータ侵害が発生しています。これらの問題の多くは、実際の IP アドレスを隠すだけで回避できます。

解決策: 潜在的な攻撃者の生活をより複雑にする

サーバーの実際のIPアドレスを隠すことで、攻撃者がシステムを攻撃することがはるかに困難になります。コンテンツ配信ネットワーク（CDN）またはDDoS保護サービスを使用すると、非常に効果的です。一般的なオプションは次のとおりです。クラウドフレアはCDN機能とDDoS保護を無料で提供しており、次のようなサービスも提供しています。インペルヴァ（旧Incapsula）は同様の機能を提供し、キュレーターは、Web アプリケーションファイアウォールを使用して Web アプリケーションを保護することに特化していますが、コストが発生する可能性があります。

これらのツールはセキュリティを大幅に強化できますが、考慮すべき追加の点があります。

電子メールヘッダー IP 漏洩: 電子メールの送信にメインサーバーを使用している場合、実際の IP アドレスが電子メールヘッダーで公開され、セキュリティ対策が無駄になる可能性があります。
IP履歴とWhoisリクエスト:次のようなサービスDNS 履歴またはWhoisリクエストドメインに関連付けられた過去の IP アドレスを明らかにすることができます。実際の IP が作業ドメインにリンクされていた場合は、変更する必要があります。
DDoS 保護と API エンドポイント: API エンドポイントとして機能するドメインに DDoS 保護を使用する場合は注意してください。保護システムにより、JSON/XML 応答が HTML コードに置き換えられ、クライアント側アプリケーションの機能が中断される可能性のあるユーザー検証手順が導入される可能性があります。
送信 API リクエスト: サーバーがサードパーティの API にリクエストを送信すると、IP アドレスが誤って公開される可能性があります。このようなリクエストにはプロキシサーバーを使用すると役立ちます。プロキシを変更する方が、攻撃の余波に対処するよりも簡単だからです。

プロジェクトの実際の IP アドレスを隠すことは万能策ではないことを覚えておくことが重要です。ソフトウェアが外部ネットワークから使用するポートを閉じることは、可能な限り重要です。標準ポートの変更は議論の余地のある方法です。一部の専門家は、大きなメリットがないにもかかわらず、設定が複雑になるだけだと主張しています。多くの場合、ネットワーク TCP 接続ではなく Unix ソケットを介して対話するようにソフトウェアを構成することが望ましいです (プロジェクトとソフトウェアの両方が同じサーバー上で実行される場合)。このアプローチは、対話速度を向上させるだけでなく、開いているポートが不要になるため、セキュリティも強化します。

別のサーバー上のデータベース管理システム (DBMS) またはその他の内部サービスの場合、アクセスが厳密に制御する特定の IP アドレスに制限されていることを確認してください。この設定により、重要なシステムへの不正アクセスが防止され、セキュリティレイヤーが追加され、外部からの攻撃やデータ漏洩のリスクが最小限に抑えられます。

5. プロジェクトの依存関係とソフトウェアを更新していますか?

このアドバイスは非常に単純ですが、これもまた見落とされがちです。プロジェクトの依存関係とサーバーソフトウェアを定期的に更新してください。古くて脆弱なコードは、簡単に悪用できるため、攻撃者にとっては格好の標的となります。

解決策: 更新を自動化する

すべてを手動で更新する必要はありません。多くの自動化ツールが役立ちます。たとえば、ディペンダボットGitHub では、古くなった依存関係や脆弱な依存関係を自動的に検出し、更新を提案します。

セキュリティ証明書の更新を自動化することも重要です。暗号化しましょう証明書の更新を自動化するにはサートボット期限切れの証明書は本当に面倒ですが、更新を自動化するのは簡単な作業です。

\同じ原則がサーバーソフトウェアにも当てはまります。Linux、特にDebian/Ubuntuベースのディストリビューションを使用している場合は、無人アップグレード簡単にこのタスクを処理できます。多数のサーバーを備えた大規模なプロジェクトの場合は、次のようなツールが役立ちます。アンシブル、シェフ、傀儡、または塩ご利用いただけます。

最終的な考え

ここで紹介したヒントは、バックエンド開発者が覚えておくべきことのほんの一部です。ここでは、重要でありながらあまり議論されていないトピックに焦点を当てることにしました。 SQLインジェクションまたはCSRF攻撃。

ウェブアプリケーションのセキュリティをより深く理解するには、 OWASP財団は、貴重なリソースを提供する非営利団体です。 OWASP トップ 10同社の Web サイトに掲載されているこのドキュメントには、最も一般的で重大な Web アプリケーションのセキュリティリスクがリストされています。また、あまり知られていないものの同様に危険な攻撃に関する情報も記載されています。

開発者コミュニティは、知識が豊富で、洞察や経験を共有する協力的な姿勢を持つべきだと私は信じています。そのため、バックエンド開発に携わるすべての人にとって貴重な意見やコメントを、ぜひ皆さんに共有していただきたいと思います。