  |
はてなキーワード: SSL証明書とは
そうだね、ちょっと無理やりすぎた
でも超抽象化して考えると、SSL証明書というのは、他のホスト(上位のCA)に真正性を証明してもらうもの、と考えることができる
一方で、戸籍の実体は各自治体で管理されている水平分割(シャーディング)されたDBで、他のホストに真正性を証明してもらう必要はない
でも、実際の運用ではいろんなDBとの照合が行われるはずなので、もし偽装があれば情報不整合のエラーが発生して偽装は検知されると思われる
となると、戸籍というものも、他のホストの情報と整合していることをもってその真正性を証明することができる、と考えることもできるのではないだろうか
それに、SSL証明書は暗号を使ってはいるけど、ルート証明書については自己署名なので、「みんなが俺のこと信じてるから、お前も俺のこと信じて」以外の何者でもないんだよね
・色んなこと満遍なくやりたい
・やべー案件に何年も磔にされたくない
これが多様なサービス、アプリを作ってみたいという話なら高単価SESに行くしかない。
かなりの経験を積んだベテランじゃないと入れない世界で出身学部も見られるから相当に厳しいと思う。
フロントやバックエンド、インフラなどもやってみたいという話なら自社でウェブサービスを運用している上場企業に正社員で入るのがいいだろう。
ただし正社員ということはリリース日には何が何でもサービスインさせる立場になるということでもある。定時退社の社風であっても進捗上がってないなら稼動上げて対応ということは普通にある。
派遣で入ればそういうことは無い。上場企業ならコンプラ厳しいからね。でも数ヶ月程度、長くて数年のスポットになることがほとんどなので長期的にはどうなんだろうな。
ここでは俺の経験を踏まえて「自社でウェブサービスを運用している上場企業に正社員で入る」という前提で話す。
アピールすると良いのは使える言語、インフラの知見、構築と運用の経験。
全部が強い必要は無い。どれか一つが強くて他はまあなんとか程度でいい。逆に言うと全くダメですが一つでもあると厳しい。
使える言語では、C#,Javaを大きめな規模のバックエンドとして使ってるとこが多い反面、対応できる人はフリーにも派遣にもたくさんいるのでちょっと弱い。SIer出身でコード書いてたなら当然できるよね、というレベル。
今ならtypescript(javascript), pythonあたりができてgo あるいは Rust勉強してます、というのがけっこう強い。
分かってると思うが言語が使えるというのは、まっさらなPCを与えられて主要なウェブフレームワークをセットアップしてローカルホストを立てるとこまでを含む。
JavaならSpringboot+gradle+JUnit、PHPならLaravel、pythonならdjango、typescriptならNode+React+knex、あとJestかDreddも入るかな。
インフラ知識では、クラウド、オンプレ両方のメリットデメリットを把握しているとよい。
AWS,Azure,GCP,Oracle Cloudのどれでもいいけど実際に使った経験があるとよい。俺は個人でGCPを契約してkubernetesとVM、LBを使っている。
ネットワークの知識は薄くでも持っていた方がよい。HTTPとかcookieとかセッションとか知りませんCORSって何ですか？レベルでは無理。まあここら辺はウェブサービスを作れば必ずやるので大丈夫だろう。
LetsでSSL証明書を作ってopensslで検証してnginxに適用してHTTPS化ができるならアピールになる。
dockerはもうそろそろ使えて当然のレベルになってきているので必須。実際ウチではdockerが分からない使えない人は面接へ進めないようになっている。
構築と運用では、予算内に収まるような構築と運用、サービスインした後のトラブルシューティングの経験があるとよい。
常にコスト意識を持っていることが必要。クラウドは油断すると100万程度すぐ飛ぶ。コスト意識が無い人を運用担当として採用することは絶対にない。
トラブルシューティングで重視されるのはベンダー対応よりもエンドユーザー対応の方。
サービスを早急に復旧させること、そのためにどういう仕組みが必要なのか、構築するところから語れる知見があるとよい。もちろんそこにもコスト意識は必要。
CI/CD、PrometheusやDatadogによる監視とアラートについて語れるとよい。
CI/CDを扱うということは当然gradle,maven,yarn,シェルスクリプトは書けて使えてwebpack,minify,Jenkinsのコンフィグもできるということである。
どうだろう、かなり雑に書いたが雰囲気は伝わると思う。
あ、git使えないは論外。もし使えないなら今すぐ使えるようになるか諦めるかのどちらかで。
★★再追記
レンタルサーバは、自由度が低くてストレスになるからやらない。SQLでwith使いたいからMySQL8をって言ってもさくらレンタルサーバじゃ無理なんでしょ？ あと同居利用者のせいで高負荷ってのも避けたい。そこを気にしない人はレンタルサーバでいいと思うよ。
あと LB $0.025/h だった。月2000円くらいか。
★追記
LBは独自ドメイン+自動更新無料SSL証明書のためね。Cloud Storageの無味乾燥なドメインでいいなら、SSL自動かつ無料でほんとに月数円。
－－－－－－－
もうねめんどくさいんだわ。もちろん以前はそうやってたよ。
PHPだのApacheだのMySQLだのインストールしたり設定ファイル置いたり、
脆弱性対応したり、SSL証明書更新したり、一応落ちてないか無料監視サービス使ったり。
でも仕事ならともかく、趣味だからこそこんなことやりたくないじゃん。
なので、コンテンツは Cloud Storage に置く。
Cloud Load Balancing も使う (無料 SSL 証明書のために)。
動的部分は Cloud Functions で。
AWS なら S3+ALB+Cognito+Lambda だな。
そうしておけば、放置できる。自前で立てたマシンもインスタンスもないから落ちてるかどうかとか気にしなくてもいい。負荷も考えない。クラウド様がよきにはからってくれるさ。たまにクラウド障害あるかもしれないけど、Google なり AWS なりが頑張って直してくれる。
って感じ。
ちなみにこちらは 1日数十アクセスの過疎サイト。独自ドメイン+自動SSL証明書にするための Cloud Load Balancing に 4000円くらい払ってる。それがなければ月数円。
表記の件について意見募集が開始された (https://www.digital.go.jp/posts/ckWVVAya) というので仕様(https://cio.go.jp/sites/default/files/uploads/documents/digital/20210917_spec_01.pdf)を見たら、なんか国のお墨付きの個人情報の名簿登録補助ツールみたいな上に、証明書としては全然機能不足にしか見えず、がっかりした。
批判だけでもなんなので、自分ならこういうの作るという意見書出しといた。
などの理由から、有益とは思えないし、電子証明書としての信憑性も非常に疑わしいシステムしかできないように思われる。
この仕組みを活用したい立場としては、「接種者の個人情報」ではなく、「二次元コードを提示した人が接種済みであること」が確認できればよいので、
2. 申請した個人（ないし端末）毎に、APIサーバでユニークなIDを発行する
3. システムの接種確認用APIに2.のIDを付けたURLをQRコードで表示する（IDを種として、ワンタイム識別子をアプリとサーバで計算するなどの設計も考えられる）
4. APIにアクセスすると、接種証明情報として、最終接種回数と接種日のみを返す
2. QRコードのURLが偽サイトではないことを検証する（HTTPSのSSL証明書確認ぐらいでも十分で、政府が発行する公式アプリとすることで信憑性を担保する）
もっと踏み込むと、国として、接種証明として表示した国民の個人情報が、民間企業において確度の非常に高い顧客名簿になりかねない、という点については、どのように考えているのかはなはだ不安を感じさせる仕様と言わざるを得ない。
（ここまで）
いま読み返していて単純に「IDを種」にするだけではダメなことに気づいた。申請時にワンタイムトークン計算用の秘密の種を共有しておいて、個人（端末）の識別用IDとワンタイムトークンをAPIに渡すようにする、とかが必要だった。
国民の個人情報を、わざわざマイナンバーカード使って本人性を保証した上で自動読み取り可能な形でスマホの画面に表示するだけのアプリって、どこぞのeKYCの対極ネタとしては面白い（面白くない）。
4台のPCに一つずつ稼働させることにした。
【よかったこと】
・IISというWindowsのサーバー建てるフレームワークみたいのを使って初めてWindowsでサーバーを建てる経験を得られた。
Windowsでサーバーを立てるのは規約違反だった気がしたが最近はWindowsに元々サーバーを建てる機能が付属してるし別にいいのだろう。
・Windows10のドライバ認識能力のすごさを知ることができた。
Linuxだとファンが回らない、何も映らないけどWindowsだと普通に動くなどした。
・Windowsでサーバーを建てるのはムズイという知見を得た。
・信じられないくらい遅い
CPU使用率が低いままで全く変わらず、にもかかわらず簡単なウェブページの表示に10秒とか待たされて使い物にならなかった。Xubuntuに変えたら1秒以内に表示された。
httpsにリダイレクトされるのをやめさせようとしたり、SSL証明書を設定しようとしたがどうやってもできなくてWindowsを使うこと自体を辞めた。
・家に余ってたHDDを全部繋げて1.5TBのクラウドサーバーを作ることができた。
複数のHDDを一つのHDDとして扱う技術（LVM）の設定をする体験ができた。1.5TBの使い道はない。不用品の処分をするのが目的。
・XubuntuならMacbookPro(2007年製)にUSBメモリからインストールできることを知った。ただしインストール画面がたまにしか表示されない。
【デメリット】
・今までは仮想マシンで動かしていたので扱いやすかったのだがそれができなくなった。
失敗しても5分前の状態に戻すとかできないし、仮想イメージのエクスポートとかできない。
・電気代を4倍食うようになった。
別に珍しくもない話じゃないかと思うけど、最近もなんかあったの？
オレオレ詐欺的なヤツはソーシャルハックだからオンライン化するしないってのは関係ないけど
公式でオンライン化しちゃうと区別のつきにくい模倣ってのはどうしても取り締まりきれないよね。
最近はGoogle様も「お前らどうせSSL証明書の内容なんかそんなに見ねーだろ？」って表示を分かりづらくさせる方向だし
独自エンジンのブラウザってFirefoxしかねぇけどアンチ広告な姿勢のせいで企業のサポートどんどん得られにくくなるだろうし
以前は信頼できなかった。
使い勝手も悪かった。
利用していない遠方の金融機関で
「「最新バージョンで利用して下さい」のような警告が出たら、
OK も キャンセル も押さずに 右上の Xボタン をクリックして下さい」
と案内があると(警告無視推奨)、
急場しのぎには仕方ないのだろうが、1年以上対応そのまま。
ワンタイムパスワードや2段階認証など、
以前の体験や見聞により、金融機関のネット利用手続きには不安が大きい。
令和 2020 年代に入り、悪い病も流行し、ネットで済むなら利用したい。
しかし怖い。
信頼できないシステムを使いたくない。
https://anond.hatelabo.jp/20200417230216
弊社の新規事業でWebサービスを作っていて、セキュリティトレンドの常時SSLってやつをやってみようと思った。
世のWebサービスを見てみるとやっている所が何故かほとんどなく、mixiやニコニコなどの大手もやってないようだ。ニコニコのURLを試しにhttpsにしてみたら繋がらず、mixiはhttpにリダイレクトされる。
うちは新規だから最初からhttps化することで特にデメリットはないと判断、安いSSL証明書を買ってhttpをhttpsにリダイレクトするようにした。技術的な難所はまったくないので問題なく実装完了し、これで安心度がちょっと上がったと思っていたのだが…。
つづく。
続き。
弊サービスではユーザーがYouTubeなどの動画を貼り付ける機能が重要なのだが、テストしてみるとニコニコ動画の埋め込みが動作しなくなっていた。調べてみるとニコ動の埋め込みコードがhttpなせいで、さらに最近のブラウザはhttpsページの中にhttpコンテンツがあると、警告も出さずまったく表示しない仕様になっているようだ。
何か解決方法はないかと調べてみると逆に、同じ理由でhttps未対応の広告やアフィリエイトも貼れないことが判明。広告モデルの無料サービスなのでこれは致命的。
というわけで当初の予定とはまったく反対の、httpsをhttpにリダイレクトする羽目になるという笑えるオチになってしまった（httpsで見られると広告なくなっちゃうため）。それでmixiもニコニコも対応してなかったのか…。
