公開にあたってコストと候補の想定
手っ取り早く思いつくのは、AWS
AWSで公開の場合、数百円程度/月の雑試算だが、じっくり就職活動を行おうと思っているので、極力コストは下げたい。
無料サービスの組み合わせ
Vercel, Render, Neonなどの複数サービスの無料プランのみで実現する方法を取った
注意：Renderは無料プランの場合、初回アクセス時時間かかる
※Renderの無料Webサービスは、15分間アクセスがないと停止し、再起動に約1分かかる。
ページへの初回アクセス時にページの表示までに時間がかかったり失敗することが想定されますので、ポートフォリオのURLの近くに、「無料プランのため初回アクセス時に時間かかるかも」みたいなことは書いておきましょう。
Git管理
Gitで開発を始める前にやればよかったこと
※チーム開発の場合、Gitでリポジトリを作る前に、まずポートフォリオへの利用・公開許可をチームで合意しておく
Gitのコミット履歴には、作成者の名前やメアドが記録される。
個人メアドや本名設定してる人は、特段対策してなければ基本表示されてしまうと考えよう。
公開用に自分のリポジトリへコピーする場合も注意が必要！
- cloneやforkなど、過去のコミット履歴を引き継ぐ方法では、作成者情報も引き継がれる。
- ソースコードだけをコピーして新しくGit管理を始めれば、過去のコミット履歴は引き継がれない。ただし、元のIssueやPR履歴も引き継がれない。
- 公開前には、コミット履歴だけでなく、ファイル内にも個人情報や機密情報が残っていないか確認する。
公開後にコミット履歴を修正するのはどえらい手間がかかるため、開発開始時から公開を意識しておくのが大事。
Email非公開設定
GitHubでは、コミットに使うメールアドレスとして、個人のメールアドレスを公開しないためのnoreplyアドレスを設定できる。
ただし、途中で設定を変更しても、過去のコミットに記録されたメールアドレスは自動では変更されない。
また、個人のメールアドレスを公開するpushをブロックする設定を有効にすると、push時にエラーになる場合がある。
最初から設定しておけばよかった！！！
Gitにアップロードするものを選別
.gitignoreなどでしっかり指定しておく
当然だがPasswordなど機密情報はアップロードしない、.env等のファイルもアップロードしない！
本番公開後の保守って何やるの？ 保守対応の経緯
なんか怪しいニュース見た。脆弱性対応？何やったらいいの？
- 本番環境に公開して2、3日くらいで、PHPの脆弱性が話題になる中、Node.jsにもセキュリティアップデートが必要になることがあるとネットの書き込みで初めて知る。
- とりあえずAIに相談しながら、ローカル環境のNode.jsと依存パッケージを更新。npm auditで脆弱性を確認した。本番環境に再デプロイした。
- Node.js本体とnpmで管理する依存パッケージは別物で、それぞれの脆弱性に対応する必要があることを知った。
- 毎回脆弱性騒ぎのたびに、まず情報を常にキャッチアップ、手動でauditして、手動で修正対応して・・・ってやっていく未来を想像して途方にくれる。
- 何かしら自動化できないかな？自動化ツール駆使を検討。そこでDependabot！！！
そもそも今回の対応必要だった？？
影響調査
自身の公開したWebサイトを構成するNode.jsに脆弱性があったことと、私のサイトを実際に悪用できることは別であるので、実務ではまず「影響調査」をします
- 自分が使っているNode.jsのバージョンは影響を受けるか？
- 自分のアプリに、その脆弱性を悪用される可能性があるか？
- どのくらい緊急性が高いか？
※個人開発ではこの2つを比較して対応せず、を選ぶことも多い
- 影響調査に何時間もかける
- 更新して、テスト・動作確認を行う
対応、いらなかったかも
正確には、今回の更新がどのくらい緊急に必要だったのかは、今も分かっていない。
今回は、自分の知識と調査にかかる時間を考えて、早期更新を選択した！ っていうとカッコいいが、、、
脆弱性が発表されたら、とにかく更新すればいいと思っていた。でも実際には、影響や緊急度を調べて判断するという過程があることを知った。
とはいえ、今回の自分には詳しい影響調査より、さっさと更新して動作確認する方が現実的なのでしばらくは付き合っていく必要がある。。。
保守対応を楽にしていくツール
Dependabot
DependabotとはGithubが提供する、脆弱性情報の確認から修正案の作成まで、一部の保守作業を自動化できるGitHubの機能
注意点： DependabotがPRを作っても、更新後にアプリが正常に動くかは自分で検証する必要がある！！
Dependabotを導入すれば安心？
残念ながら、Dependabotですべての脆弱性を検知できるわけではない。
修正用PRが作成されても、更新後にアプリが正常に動作するかは自分で確認する必要がある。
Dependabotは保守作業を減らしてくれる便利な機能だが、保守そのものをすべて任せられるわけではない！
Dependabot alerts：脆弱性の通知
役割：既知の脆弱性を検知して通知
動作タイミング：新しい脆弱性情報や依存関係の変更を検知したとき
公開したばかりなのに8件も！！！
Dependabot security updates：修正用PRの自動作成
役割：脆弱性を修正するためのPRを自動作成
動作タイミング：対応可能な脆弱性が検出されたとき
※修正版が存在しない場合や、他のパッケージとの依存関係によって更新できない場合は、PRが作成されないこともある。
Dependabot version updates
役割：パッケージを新しいバージョンに更新するPRを作成
動作タイミング：.github/dependabot.ymlで設定したタイミング
設定するには
リポジトリ → Settings → Advanced Security → Dependabot version updates → Enable
上記のように進め、設定ファイルのひな形を作成。編集してコミットすれば有効になる
↓パッケージの更新確認を週1回自動実行するよう設定した
自身のポートフォリオサイトの脆弱性対応をする必要性
そもそも個人のポートフォリオサイトでも、脆弱性対応って必要なの？
多数のユーザーが利用するサービスでもないし、個人情報を大量に蓄積・活用するわけでもない。それでもセキュリティ対策は必要なのか？
対応しなきゃいけない理由あります！
脆弱性を悪用されると、サイトの改ざんや不正利用だけでなく、サーバーが乗っ取られ、他のWebサイトへの攻撃の「踏み台」にされる恐れがあります。
例えば、多数の機器から大量のアクセスを送りつけ、サービスを停止させるDDoS攻撃など。
個人情報を扱っていなくても、自分のサイトが第三者への攻撃に利用される可能性があるため、脆弱性への対応は必要だと学びました。
適切なセキュリティ対策を怠った結果、第三者に損害が発生した場合には、状況によって民事上の責任を問われたり損害賠償の可能性もあります。
個人のポートフォリオであっても、公開する以上はセキュリティ対策や継続的な保守が必要だと学びました。
自分が作ったものを公開する、ということは単に動くアプリをインターネットに置くことではなく、そのアプリが第三者に与え得る影響まで考えることなのである。